@NUXT/SCHEMA · GHSA-mjrq-cffv-q4qc · Package
FIX → 4.6.4
The Nuxt development server can serve any file under a parent directory when a stray lockfile or settings file sits above the project. An attacker who can reach the dev server over the network can read files such as SSH keys and cloud credentials in that directory.
first public Nov 2, 2026 · 1 source
Could this affect your app?
Free first check from your website. Connect your repo for the full answer.
Only the development server (nuxt dev) is affected, not production builds. Exposure needs a lockfile or settings file such as pnpm-workspace.yaml or deno.json in a parent directory, the project outside any git repository, and the dev server reachable from the network through --host, --tunnel, a published container port or a proxy. Teams that keep the dev server on localhost, or have no stray files above their projects, can skip it.
Not affected if localhost-only, managed-hosting, no-parent-lockfile, production-build
Who cares developers, npm, nuxt, self-hosted
npm ls @nuxt/schema or check node_modules/@nuxt/schema/package.json for a version below 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, , and similar) above it. Running once in the home directory is enough to create one there.Check it with your coding agent
It reads this page and tells you if your code is affected.
Are you affected?
Ask from here. InfraStack checks the affected versions against your stack and answers in your inbox.
InfraStack checks the affected versions against your stack and answers in Slack, with the evidence and the fix.
4.6.4package-lock.json, pnpm-lock.yaml, yarn.lock or bun.lock in parent directories above the project, such as the home directory, with no git repository around the projectnuxt dev runs with --host or --tunnel, or the dev port is published from a containerUpgrade to 4.6.4
@nuxt/schema 4.6.4 (affected >= 4.0.0, < 4.6.4; nuxt 4.6.4 depends on it)>= 3.5.0, < 4.0.0): no fix, Nuxt 3 has reached end of life; the advisory suggests setting workspaceDir explicitly in nuxt.config.tsturbo.jsonlerna.jsonnpm installpnpm-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.
Thanks to @superboy-zjc for the report.