GHSA-RQ7W-G337-39QQ
Vulnerability from github – Published: 2026-06-15 20:56 – Updated: 2026-06-15 20:56Summary
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 tonode_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:
- LAN-adjacent attacker when the developer runs
nuxt dev --host(or otherwise binds to a non-loopback interface). A plaincurl http://<dev-lan-ip>:3000/.well-known/appspecific/com.chrome.devtools.jsonreturns the JSON; no browser, no CORS. - DNS rebinding against the default loopback dev server. A page the developer visits resolves to the attacker, then re-resolves to
127.0.0.1after 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.
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "nuxt"
},
"ranges": [
{
"events": [
{
"introduced": "4.0.0-alpha.1"
},
{
"fixed": "4.4.7"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-200"
],
"github_reviewed": true,
"github_reviewed_at": "2026-06-15T20:56:22Z",
"nvd_published_at": null,
"severity": "LOW"
},
"details": "### Summary\n\nWhen 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`.\n\nThe endpoint exists to let Chrome DevTools\u0027 Workspace integration map sources to the developer\u0027s 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.\n\n### Impact\n\nDev-server only. Production builds do not register the route.\n\nTwo values are disclosed:\n\n- `workspace.root`: the absolute filesystem path of the project (commonly reveals the OS username and the on-disk project name).\n- `workspace.uuid`: a v4 UUID persisted to `node_modules/.cache/nuxt/chrome-workspace.json`, stable across dev-server restarts and re-clones.\n\n### Threat model\n\nThe response carries no `Access-Control-Allow-Origin` header. A cross-origin `fetch()` from an arbitrary malicious page is therefore blocked by the browser\u0027s same-origin policy and cannot read the body. The two realistic recovery paths are:\n\n1. **LAN-adjacent attacker** when the developer runs `nuxt dev --host` (or otherwise binds to a non-loopback interface). A plain `curl http://\u003cdev-lan-ip\u003e:3000/.well-known/appspecific/com.chrome.devtools.json` returns the JSON; no browser, no CORS.\n2. **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.\n\n### Affected versions\n\n`nuxt@4.0.0-alpha.1` (PR #32084) through `nuxt@4.4.6`. `3.x` is not affected.\n\n### Reproduction\n\n```bash\nnpx nuxt dev\ncurl -s http://localhost:3000/.well-known/appspecific/com.chrome.devtools.json\n# {\"workspace\":{\"uuid\":\"...\",\"root\":\"/Users/\u003cname\u003e/...\"}}\n```\n\n### Workaround\n\nSet `experimental: { chromeDevtoolsProjectSettings: false }` in `nuxt.config.ts`. Chrome DevTools\u0027 Workspace auto-integration will stop working; the dev server is otherwise unaffected.\n\n### Patches\n\nFixed 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.",
"id": "GHSA-rq7w-g337-39qq",
"modified": "2026-06-15T20:56:22Z",
"published": "2026-06-15T20:56:22Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/nuxt/nuxt/security/advisories/GHSA-rq7w-g337-39qq"
},
{
"type": "WEB",
"url": "https://github.com/nuxt/nuxt/pull/35201"
},
{
"type": "WEB",
"url": "https://github.com/nuxt/nuxt/commit/55c75b78c989b8bd210837b0e5faaebbf2b87b15"
},
{
"type": "PACKAGE",
"url": "https://github.com/nuxt/nuxt"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "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",
"type": "CVSS_V4"
}
],
"summary": "Nuxt: Dev server discloses project absolute path and persistent workspace UUID via `/.well-known/appspecific/com.chrome.devtools.json`"
}
Drag nodes to arrange them. Double-click a related vulnerability to open it, or a source to visit its link. The Physics button on the left tunes the layout and the simulation; the legend at the bottom left hides or shows nodes by kind and by sighting type.
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
Vulnerability timeline
Sightings and recorded dates, grouped by day · UTC
How durations are calculated
Following the VTEM framework (Black Hat USA 2015), time to patch starts when the vendor or a coordinator was informed, total time to patch at discovery, and disclosure to patch at public disclosure; vendor response time runs from the report to its acknowledgement. Time to exploit and time unpatched start at the earliest discovery or report, falling back to public disclosure. Unpatched time ends at the first recorded patch, or the calculation time when no patch is recorded. Exploitation to patch shows the interval between those two events; a published proof of concept is a public exploit, not exploitation.
Each result shows its source dates. A negative interval means the end event came first; when date-only inputs leave the order open, the result says so. Date-only inputs are approximate. The earliest evidence wins: KEV report dates and sightings are labelled as such. Records describing another vulnerability are listed but never calculated from, and a PoC alone does not establish exploitation. Missing patch evidence does not prove that no patch exists. Filters below change the event list only.
Loading timeline…
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.
Related by attack behaviour
Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.