GHSA-rq7w-g337-39qq json
Nuxt: Dev server discloses project absolute path and persistent workspace UUID via `/.well-known/appspecific/com.chrome.devtools.json`
published 5mo ago modified 4mo ago
- cvss
- 2.3
- version 4.0, the maintainers
- cisa kev
- Not listed
- not in CISA's catalog
- epss
- —
- no score, EPSS covers CVEs only
- public exploits
- 0
- none known
Summary
### 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
```bash 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](https://github.com/nuxt/nuxt/pull/35201) (commit [`55c75b78`](https://github.com/nuxt/nuxt/commit/55c75b78c989b8bd210837b0e5faaebbf2b87b15)). 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.
Patch / fix
Is GHSA-rq7w-g337-39qq in your dependencies? Fencer shows which of your repositories are affected as soon as an advisory lands, and opens the fix as a pull request.
Check with FencerCVSS scores
| assigned by | version | score | vector |
|---|---|---|---|
| the maintainers | 4.0 | 2.3 | CVSS:4.0/AV:A/AC:L/AT:P/PR:N/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N |
Affected packages
| ecosystem | package | affected | fixed in |
|---|---|---|---|
| npm | nuxt | >=4.0.0-alpha.1, <4.4.7 |
4.4.7 |
Classification
- Weakness
-
- CWE-200 Exposure of Sensitive Information to an Unauthorized Actor
References
Sources
- GitHub Advisory GHSA-rq7w-g337-39qq
- Maintainer advisory GHSA-rq7w-g337-39qq
Fencer Intel keeps one entry per vulnerability: the CVE id wins, then GHSA, and records that alias each other are merged, except that two CVEs always keep separate entries. The same data is available as JSON.
The maintainers of nuxt/nuxt published their own advisory on GitHub. Reviewed sources take precedence over it.