
Loading

Loading
We use strictly necessary cookies to run this site, and analytics cookies to understand how it's used. See our Privacy Policy for details.
A GitHub-reviewed security advisory, not necessarily under active exploitation the way our CISA KEV advisories are, but a real, disclosed vulnerability in an open-source dependency.
Affected packages
Vulnerable: >= 3.5.0, < 4.6.4
Patched in 4.6.4
Details
Nuxt can pick a parent directory that does not declare a workspace as its default workspaceDir: the farthest directory with a lockfile when the project is not inside a git repository, or the farthest directory with a pnpm-workspace.yaml or deno.json file, even one that only holds settings. The Vite dev server allows /_nuxt/@fs/ requests for any file under workspaceDir. A stray lockfile or settings file in a parent directory, such as the home directory, therefore lets anyone who can reach the dev server read files in that directory and everything below it.
This affects the development server only; production builds are not affected. All of the following have to hold:
package-lock.json, pnpm-lock.yaml, yarn.lock, bun.lock and similar), while the project is not inside a git repository and has no workspace file (pnpm-workspace.yaml, turbo.json, lerna.json and similar) above it. Running npm install once in the home directory is enough to create one there.pnpm-workspace.yaml without a packages list (for example one that only holds pnpm settings such as onlyBuiltDependencies), or a deno.json or deno.jsonc without a workspace field. This applies even if the project is inside a git repository.nuxt dev --host, nuxt dev --tunnel, a published container port, or a proxy onto the dev port). The default localhost bind limits this to local processes, which can usually read the same files directly.For example, with ~/package-lock.json and a project at ~/projects/app that has no .git directory, nuxt dev --host serves GET /_nuxt/@fs/<home>/.ssh/id_ed25519 with status 200. Any file in the home directory that is not covered by Vite's server.fs.deny list can be read this way, including SSH keys, cloud credentials and the Nuxt DevTools auth token in ~/.nuxt/devtools/dev-auth-token.txt.
No browser is involved: a plain HTTP client is enough. A web page on another origin cannot read the response, and DNS rebinding is rejected by Vite's host check.
Projects whose parent directories contain none of these files are not affected, nor are projects inside a git repository whose only lockfile is their own. Nuxt 3.5.0 and later are affected.
Fixed in @nuxt/schema 4.6.4, which nuxt 4.6.4 depends on. A parent directory now only becomes the default workspaceDir if it declares a workspace: a pnpm-workspace.yaml with packages, a deno.json or deno.jsonc with workspace, a lerna.json, turbo.json or rush.json, a package.json with workspaces, or a git repository. A lockfile or a settings file alone no longer widens the dev server's server.fs.allow list. If your monorepo root is not detected this way, set workspaceDir in nuxt.config.ts. Nuxt 3 has reached end of life and will not receive a fix.
Set workspaceDir explicitly in nuxt.config.ts to the project root (or to the real monorepo root), or remove the stray lockfile or settings file from the parent directory. Do not expose the dev server to untrusted networks. If the dev port was reachable from an untrusted network while this layout was in place, treat files in the parent directory as exposed and rotate credentials such as SSH keys and cloud tokens.
Nuxt thanks @superboy-zjc for the report.
More npm advisories
Talk to us about this
Find out whether this dependency (or others like it) is actually reachable in your codebase.
Get help patching, or building dependency-scanning into your pipeline going forward.
A secure code review or supply chain review finds this before an advisory does.