- Nuxt's development server can serve files from a parent folder, such as a home directory, when a stray lockfile or settings file sits there and the server is reachable on a network.
- Production builds are not affected, according to the Nuxt advisory. Nuxt 3.5.0 and later are affected; the fix ships in Nuxt 4.6.4, and Nuxt 3 gets no patch.
- Teams should upgrade, set workspaceDir explicitly, remove stray files, and rotate credentials if a dev port was reachable from an untrusted network.
The tool guessed where the project ends
Developer tools make small guesses all day. One of them is how far a project extends. The Nuxt advisory GHSA-mjrq-cffv-q4qc shows what happens when that guess is wrong. In certain folder layouts, the tool decided a project reached up into the home folder. When the dev server was reachable from a network, it then offered nearly everything in that folder to anyone who asked.
The lesson is that a laptop is not a neutral workspace. The same machine that runs a half-finished web app also holds SSH keys and cloud credentials. A convenience setting that widens the boundary by accident puts those files within reach.
What the Nuxt team reports
The advisory was published on the GitHub Advisory Database on November 13. It covers the development server only. The advisory states that production builds are not affected.
Nuxt decides which folder counts as the project's workspace. In some layouts it picks a parent folder that never declared itself a workspace. The advisory describes two situations that trigger this.
The first involves a package lockfile in a parent folder. The project sits outside any git repository, and no recognised workspace file exists higher up. The second involves a parent folder with a pnpm settings file that lists no packages, or a Deno config file that has no workspace field. The second situation can arise even inside a git repository.
The first situation is easy to create by accident. According to the advisory, one run of npm install in the home directory leaves a lockfile there.
How the exposure works
Nuxt's dev server is built on Vite, a development tool that serves files to the browser. Vite lets requests to a path beginning /_nuxt/@fs/ reach any file under the workspace folder. When Nuxt picks the home folder as the workspace, everything below it becomes fetchable, apart from files on Vite's protected list.
The advisory gives an example. With a package-lock.json in the home folder and a project at ~/projects/app with no .git directory, running nuxt dev --host serves a request for the home folder's .ssh/id_ed25519 file with status 200. That is the success code for a normal page.
The advisory says a plain HTTP client is enough. No browser is involved. Two limits apply. A web page on a different origin cannot read what comes back, and Vite's host check turns away DNS rebinding attacks. Files on Vite's server.fs.deny list stay protected.
Most other files in the home folder are fair game. The advisory lists SSH private keys and cloud login details as examples, and it also points to the token that Nuxt DevTools keeps under ~/.nuxt/devtools.
One more condition has to hold. The dev server must be reachable from the network. The advisory names several ways this happens: starting the server with the --host or --tunnel option, publishing a container port, or putting a proxy in front of the dev port. With the default localhost setting, only processes on the same machine can connect. The advisory notes those can usually read the same files directly.
Who is affected, and what is fixed
Per the advisory, every Nuxt release from 3.5.0 onward is affected. The patched code lives in @nuxt/schema 4.6.4, a package that nuxt 4.6.4 pulls in. After the fix, a parent folder becomes the default workspace only if it declares one. Declarations that count include a pnpm workspace file with a packages list, a package.json with a workspaces field, lerna, turbo or rush configuration, or a git repository. A lockfile or settings file by itself no longer widens the allowed area.
Nuxt 3 is past end of life, and the maintainers say it will get no fix. Teams still on it carry this exposure until they migrate or apply the workarounds below.
What leaders should ask their teams
This flaw needs a particular layout and a reachable dev port. Teams without a stray file in a parent folder, or without a network-reachable dev port, are not exposed. Four questions follow from the advisory's guidance.
First, which projects run Nuxt, and on which version? Anything on Nuxt 3 needs a migration plan or the workarounds.
Second, do developers start the server with --host or --tunnel, or publish its port from a container? Ask which networks can reach those ports.
Third, do home folders contain stray lockfiles or settings files? The advisory offers two remedies. Name the project root, or the true monorepo root, in the workspaceDir setting of nuxt.config.ts. Or delete the stray file.
Fourth, was a dev port ever open to an untrusted network while this layout existed? If so, the advisory says to treat the parent folder's files as exposed. In that case, the maintainers advise changing any SSH keys and cloud access tokens that lived there. They also say the dev server should stay off untrusted networks.
The Nuxt team credits @superboy-zjc for the report. The broader point is that development shortcuts deserve the same scrutiny as production. A tool that guesses its own boundaries can hand out more than anyone meant to share.
Produced by the WebPulse Newsroom with AI assistance from the original reporting credited below, and checked against that source by our editorial review. How we use AI.
Original reporting: GitHub Advisory Database.
