Nuxt dev server discloses project root and workspace UUID via the Chrome DevTools workspace endpoint (CVE-2026-72744)
### Impact When a Nuxt dev server is bound to a network-reachable interface (for example `nuxt dev --host` for on-device testing), the default-enabled Chrome DevTools workspace endpoint `GET /.well-known/appspecific/com.chrome.devtools.json` returns the absolute project root (`workspace.root`, i.e. `rootDir`) and a persistent per-project workspace UUID. `GHSA-rq7w-g337-39qq` added a gate (`isLocalDevRequest`) intended to restrict this endpoint to local requests, but that gate is header-based: it trusts request metadata rather than the connected peer address. A request with no `Sec-Fetch-Site`, `Origin`, and `Referer` headers (normal for a non-browser client such as `curl`) is treated as local, and the `Host` allow-list is compared against the attacker-supplied `Host` header. As a result, any unauthenticated host that can reach the dev server on the LAN can retrieve the project's absolute filesystem path and workspace UUID, for example with `curl -H 'Host: localhost' http://<dev-host-lan-ip>:3000/.well-known/appspecific/com.chrome.devtools.json`. This is information disclosure only: there is no file read, file write, or code execution reachable from the endpoint. It requires the dev server to be reachable beyond loopback and `experimental.chromeDevtoolsProjectSettings` to be enabled (it defaults to `true`). Production builds are unaffected, because the endpoint is registered only as a development handler. ### Patches Fixed in `[email protected]` and `[email protected]`. The endpoint now additionally requires the connected TCP peer to be a loopback address, verified from the socket rather than from request headers, so a non-loopback LAN client is rejected regardless of the `Host`, `Origin`, `Referer`, or `Sec-Fetch-*` headers it sends. The shared header-based check is left unchanged, so the CSRF / same-origin behaviour that other dev handlers rely on is preserved. After this fix, Chrome DevTools workspace auto-mapping only works when the browser reaches the dev server over loopback (`localhost` / `127.0.0.1` / `::1`), which matches the feature's intent (the browser and dev server sharing a filesystem). ### Workarounds - Do not bind the dev server to a non-loopback interface on an untrusted network, or restrict access to the dev port with a firewall. - Disable the feature by setting `experimental.chromeDevtoolsProjectSettings: false` in `nuxt.config`.
AI Analysis
Technical Summary
When a Nuxt dev server is accessible on a network interface beyond loopback and the experimental Chrome DevTools workspace feature is enabled, the endpoint GET /.well-known/appspecific/com.chrome.devtools.json discloses the absolute project root directory and a persistent workspace UUID. The vulnerability stems from an insufficient access control check that trusts request headers (Host, Origin, Referer) rather than the actual TCP peer address, allowing any unauthenticated client on the LAN to access this endpoint by spoofing headers. This is an information disclosure vulnerability only; no file read/write or code execution is possible through this endpoint. Production builds are unaffected as the endpoint is only registered in development mode. The issue was patched in Nuxt 4.5.1 and 3.21.10 by requiring the TCP connection to originate from a loopback address, ensuring only local clients can access the endpoint. The patch preserves header-based checks to maintain CSRF protections for other dev handlers. Workarounds include not binding the dev server to non-loopback interfaces on untrusted networks or disabling the feature via configuration.
Potential Impact
This vulnerability allows an attacker with network access to a Nuxt development server bound to a non-loopback interface to retrieve sensitive information: the absolute filesystem path of the project root and a persistent workspace UUID. While this does not enable direct file system access, code execution, or modification, it leaks internal project structure details that could aid further reconnaissance or targeted attacks. The impact is limited to development environments with the experimental Chrome DevTools workspace feature enabled and does not affect production deployments.
Mitigation Recommendations
A fix is available in Nuxt versions 4.5.1 and 3.21.10, which restricts access to the Chrome DevTools workspace endpoint to loopback TCP connections only, preventing LAN attackers from accessing it regardless of spoofed headers. Users should upgrade to these versions to remediate the issue. Until patched, mitigations include not binding the dev server to network interfaces reachable by untrusted hosts or restricting access to the dev server port via firewall rules. Alternatively, disabling the feature by setting experimental.chromeDevtoolsProjectSettings to false in nuxt.config prevents the endpoint from being exposed.
Nuxt dev server discloses project root and workspace UUID via the Chrome DevTools workspace endpoint (CVE-2026-72744)
Description
### Impact When a Nuxt dev server is bound to a network-reachable interface (for example `nuxt dev --host` for on-device testing), the default-enabled Chrome DevTools workspace endpoint `GET /.well-known/appspecific/com.chrome.devtools.json` returns the absolute project root (`workspace.root`, i.e. `rootDir`) and a persistent per-project workspace UUID. `GHSA-rq7w-g337-39qq` added a gate (`isLocalDevRequest`) intended to restrict this endpoint to local requests, but that gate is header-based: it trusts request metadata rather than the connected peer address. A request with no `Sec-Fetch-Site`, `Origin`, and `Referer` headers (normal for a non-browser client such as `curl`) is treated as local, and the `Host` allow-list is compared against the attacker-supplied `Host` header. As a result, any unauthenticated host that can reach the dev server on the LAN can retrieve the project's absolute filesystem path and workspace UUID, for example with `curl -H 'Host: localhost' http://<dev-host-lan-ip>:3000/.well-known/appspecific/com.chrome.devtools.json`. This is information disclosure only: there is no file read, file write, or code execution reachable from the endpoint. It requires the dev server to be reachable beyond loopback and `experimental.chromeDevtoolsProjectSettings` to be enabled (it defaults to `true`). Production builds are unaffected, because the endpoint is registered only as a development handler. ### Patches Fixed in `[email protected]` and `[email protected]`. The endpoint now additionally requires the connected TCP peer to be a loopback address, verified from the socket rather than from request headers, so a non-loopback LAN client is rejected regardless of the `Host`, `Origin`, `Referer`, or `Sec-Fetch-*` headers it sends. The shared header-based check is left unchanged, so the CSRF / same-origin behaviour that other dev handlers rely on is preserved. After this fix, Chrome DevTools workspace auto-mapping only works when the browser reaches the dev server over loopback (`localhost` / `127.0.0.1` / `::1`), which matches the feature's intent (the browser and dev server sharing a filesystem). ### Workarounds - Do not bind the dev server to a non-loopback interface on an untrusted network, or restrict access to the dev port with a firewall. - Disable the feature by setting `experimental.chromeDevtoolsProjectSettings: false` in `nuxt.config`.
CVSS v4.0
Affected software
Run on your own infrastructure? Check whether these packages are installed with threat-finder — our free open-source scanner.
Weaknesses
AI-Powered Analysis
Machine-generated threat intelligence
Technical Analysis
When a Nuxt dev server is accessible on a network interface beyond loopback and the experimental Chrome DevTools workspace feature is enabled, the endpoint GET /.well-known/appspecific/com.chrome.devtools.json discloses the absolute project root directory and a persistent workspace UUID. The vulnerability stems from an insufficient access control check that trusts request headers (Host, Origin, Referer) rather than the actual TCP peer address, allowing any unauthenticated client on the LAN to access this endpoint by spoofing headers. This is an information disclosure vulnerability only; no file read/write or code execution is possible through this endpoint. Production builds are unaffected as the endpoint is only registered in development mode. The issue was patched in Nuxt 4.5.1 and 3.21.10 by requiring the TCP connection to originate from a loopback address, ensuring only local clients can access the endpoint. The patch preserves header-based checks to maintain CSRF protections for other dev handlers. Workarounds include not binding the dev server to non-loopback interfaces on untrusted networks or disabling the feature via configuration.
Potential Impact
This vulnerability allows an attacker with network access to a Nuxt development server bound to a non-loopback interface to retrieve sensitive information: the absolute filesystem path of the project root and a persistent workspace UUID. While this does not enable direct file system access, code execution, or modification, it leaks internal project structure details that could aid further reconnaissance or targeted attacks. The impact is limited to development environments with the experimental Chrome DevTools workspace feature enabled and does not affect production deployments.
Mitigation Recommendations
A fix is available in Nuxt versions 4.5.1 and 3.21.10, which restricts access to the Chrome DevTools workspace endpoint to loopback TCP connections only, preventing LAN attackers from accessing it regardless of spoofed headers. Users should upgrade to these versions to remediate the issue. Until patched, mitigations include not binding the dev server to network interfaces reachable by untrusted hosts or restricting access to the dev server port via firewall rules. Alternatively, disabling the feature by setting experimental.chromeDevtoolsProjectSettings to false in nuxt.config prevents the endpoint from being exposed.
Technical Details
- Gcve Source
- db.gcve.eu
- Osv Id
- GHSA-7c4v-fwgw-9rf7
- Osv Schema Version
- 1.4.0
- Ecosystems
- ["npm"]
- Database Specific Severity
- MODERATE
- Cvss Version
- 4.0
Threat ID: 6a77432dbf8831d539b461d8
Added to database: 08/08/2026, 14:54:37 UTC
Last enriched: 08/08/2026, 15:39:48 UTC
Last updated: 09/19/2026, 04:33:01 UTC
Views: 38
Community Reviews
0 reviewsCrowdsource mitigation strategies, share intel context, and vote on the most helpful responses. Sign in to add your voice and help keep defenders ahead.
Want to contribute mitigation steps or threat intel context? Sign in or create an account to join the community discussion.
Actions
Updates to AI analysis require Pro Console access. Upgrade inside Console → Billing.
Need more coverage?
Upgrade to Pro Console for AI refresh and higher limits.
For incident response and remediation, OffSeq services can help resolve threats faster.
Latest Threats
Check if your credentials are on the dark web
Instant breach scanning across billions of leaked records. Free tier available.