LowGHSA-rq7w-g337-39qq

Nuxt: Dev server discloses project absolute path and persistent workspace UUID via `/.well-known/appspecific/com.chrome.devtools.json`

Published 15 Jun 2026 · Updated 15 Jun 2026

Affected package

nuxtnpm
Affected
>=4.0.0-alpha.1 <4.4.7
Fixed in
4.4.7
Update to the fixed version for your release line, for example:npm install nuxt@4.4.7

Details

Summary

When running nuxt dev, Nuxt registers an unauthenticated route at /.well-known/appspecific/com.chrome.devtools.json that returns the absolute filesystem path of the project root and a per-project UUID persisted to node_modules/.cache/nuxt/chrome-workspace.json. The route is enabled by default via experimental.chromeDevtoolsProjectSettings: true.

The endpoint exists to let Chrome DevTools' Workspace integration map sources to the developer's local checkout. The handler is registered directly on nitro.options.devHandlers and does not pass through the CORS / origin wrapper that the rest of the dev pipeline uses, so it has no host / origin / Sec-Fetch-Site check of its own.

Impact

Dev-server only. Production builds do not register the route.

Two values are disclosed:

  • workspace.root: the absolute filesystem path of the project (commonly reveals the OS username and the on-disk project name).
  • workspace.uuid: a v4 UUID persisted to node_modules/.cache/nuxt/chrome-workspace.json, stable across dev-server restarts and re-clones.

Threat model

The response carries no Access-Control-Allow-Origin header. A cross-origin fetch() from an arbitrary malicious page is therefore blocked by the browser's same-origin policy and cannot read the body. The two realistic recovery paths are:

1. LAN-adjacent attacker when the developer runs nuxt dev --host (or otherwise binds to a non-loopback interface). A plain curl http://<dev-lan-ip>:3000/.well-known/appspecific/com.chrome.devtools.json returns the JSON; no browser, no CORS. 2. DNS rebinding against the default loopback dev server. A page the developer visits resolves to the attacker, then re-resolves to 127.0.0.1 after the TTL; the browser believes the request is same-origin and reads the response.

Affected versions

nuxt@4.0.0-alpha.1 (PR #32084) through nuxt@4.4.6. 3.x is not affected.

Reproduction

npx nuxt dev
curl -s http://localhost:3000/.well-known/appspecific/com.chrome.devtools.json
# {"workspace":{"uuid":"...","root":"/Users/<name>/..."}}

Workaround

Set experimental: { chromeDevtoolsProjectSettings: false } in nuxt.config.ts. Chrome DevTools' Workspace auto-integration will stop working; the dev server is otherwise unaffected.

Patches

Fixed in nuxt@4.4.7 by #35201 (commit `55c75b78`). The handler is now routed through the same host / origin gate the rest of the dev server uses, so the endpoint only responds to requests that look local.

Is GHSA-rq7w-g337-39qq in any of your client repos?

Checking one package by hand is fine. Checking it across forty client projects is not. NPMscan reads the lockfiles in every GitHub repo you pick, finds each project with an affected nuxt, and gives you the command that fixes it.

References

Advisory data from OSV.dev (opens OSV.dev in a new tab), refreshed daily.