CVE-2026-128070

### Summary 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. ### Impact This affects the development server only; production builds are not affected. All of the following have to hold: - A parent directory contains either: - a lockfile (`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. - a `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. - The dev server is reachable from the network (`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