VulnerabilityPublished 7 Aug 2026Updated 13 Aug 2026

CVE-2026-72744: Nuxt dev server discloses project root and workspace UUID via the Chrome DevTools workspace endpoint

Affects nuxtSource GCVE Database

Mentioned vulnerabilities

CVE-2026-72744

CVSS 5.3 Medium : upgrade to 4.5.1 when convenient.

Data as of 13 Aug 2026, 17:47 UTC

CVSS 4.0 base score

5.3Medium

How severe the flaw is on the 0–10 CVSS scale.

Patch: Available – fixed in 4.5.1, 3.21.10

CVSS:4.0/AV:A/AC:L/AT:N/PR:N/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N

Attack Vector: Adjacent
Attack Complexity: Low
Attack Requirements: None
Privileges Required: None
User Interaction: None
Vulnerable system confidentiality: Low
Vulnerable system integrity: None
Vulnerable system availability: None
Subsequent system confidentiality: None
Subsequent system integrity: None
Subsequent system availability: None

Bold values are the worst case: easiest to exploit or largest impact.

Attack Vector: Adjacent: The vulnerable system is bound to a protocol stack, but the attack is limited at the protocol level to a logically adjacent topology. This can mean an attack must be launched from the same shared proximity (e.g., Bluetooth, NFC, or IEEE 802.11) or logical network (e.g., local IP subnet), or from within a secure or otherwise limited administrative domain (e.g., MPLS, secure VPN within an administrative network zone).
Attack Complexity: Low: The attacker must take no measurable action to exploit the vulnerability. The attack requires no target-specific circumvention to exploit the vulnerability. An attacker can expect repeatable success against the vulnerable system.
Attack Requirements: None: The successful attack does not depend on the deployment and execution conditions of the vulnerable system. The attacker can expect to be able to reach the vulnerability and execute the exploit under all or most instances of the vulnerability.
Privileges Required: None: The attacker is unauthorized prior to attack, and therefore does not require any access to settings or files of the vulnerable system to carry out an attack.
User Interaction: None: The vulnerable system can be exploited without interaction from any human user, other than the attacker.
Vulnerable system confidentiality: Low: There is some loss of confidentiality. Access to some restricted information is obtained, but the attacker does not have control over what information is obtained, or the amount or kind of loss is limited. The information disclosure does not cause a direct, serious loss to the Vulnerable System.
Vulnerable system integrity: None: There is no loss of integrity within the Vulnerable System.
Vulnerable system availability: None: There is no impact to availability within the Vulnerable System.
Subsequent system confidentiality: None: There is no loss of confidentiality within the Subsequent System or all confidentiality impact is constrained to the Vulnerable System.
Subsequent system integrity: None: There is no loss of integrity within the Subsequent System or all integrity impact is constrained to the Vulnerable System.
Subsequent system availability: None: There is no impact to availability within the Subsequent System or all availability impact is constrained to the Vulnerable System.

Definitions: FIRST CVSS v4.0 specification.

What to do

Upgrade nuxt to 4.5.1; nuxt to 3.21.10.

Affected software

Product	Affected	Fixed in
npmnuxt	Affected >=4.4.7 <4.5.1	Fixed in 4.5.1
npmnuxt	Affected >=3.21.7 <3.21.10	Fixed in 3.21.10

Check your own hosts for these packages with threat-finder (opens in a new tab), our free open-source scanner.

AI-suggested

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.

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 `nuxt@4.5.1` and `nuxt@3.21.10`. 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`.

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.

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.

CWE-200Exposure of Sensitive Information to an Unauthorized Actor (opens in a new tab)
Class weaknessLikelihood of exploit: HighCWE Top 25 (2025): #20OWASP Top 10 A01:2025: Broken Access Control (opens in a new tab)
The product exposes sensitive information to an actor that is not explicitly authorized to have access to that information.
MITRE discourages mapping vulnerabilities to this broad entry; the root cause is usually a more specific weakness.
Architecture and Design · Separation of Privilege
Compartmentalize the system to have "safe" areas where trust boundaries can be unambiguously drawn. Do not allow sensitive data to go outside of the trust boundary and always be careful when interfacing with a compartment outside of the safe area.
OWASP Cheat Sheets
Error Handling (opens in a new tab)
Logging (opens in a new tab)
Authorization (opens in a new tab)
OWASP ASVS 4.0.3
V8.3.4 (opens in a new tab)
V14.3.3 (opens in a new tab)
V7.3.3 (opens in a new tab)
Attack patterns
Subverting Environment Variable Values (opens in a new tab)
ICMP Echo Request Ping (opens in a new tab)
TCP SYN Scan (opens in a new tab)
Enumerate Mail Exchange (MX) Records (opens in a new tab)
DNS Zone Transfers (opens in a new tab)
From MITRE CWE, MITRE CAPEC and OWASP (Top 10, OpenCRE).

References

Community reviews

Loading reviews…

What to do

Affected software

Description

AI analysisMachine-generated, updated 8 Aug 2026, 15:39 UTC

WeaknessesCWE-200

Technical details

References

Community reviews

Related threats