CVE-2026-72744

Nuxt dev server discloses project root and workspace UUID via the Chrome DevTools workspace endpoint

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.

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.

Kodem intelligence

Already deployed Kodem?

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).

1. What is CVE-2026-72744? CVE-2026-72744 is a medium-severity security vulnerability in nuxt (npm), affecting versions >= 4.4.7, < 4.5.1. It is fixed in 4.5.1, 3.21.10.
2. Which versions of nuxt are affected by CVE-2026-72744? nuxt (npm) versions >= 4.4.7, < 4.5.1 is affected.
3. Is there a fix for CVE-2026-72744? Yes. CVE-2026-72744 is fixed in 4.5.1, 3.21.10. Upgrade to this version or later.
4. Is CVE-2026-72744 exploitable, and should I be worried? Whether CVE-2026-72744 is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
5. What actually determines whether CVE-2026-72744 is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
6. How do I fix CVE-2026-72744?
   • Upgrade nuxt to 4.5.1 or later
   • Upgrade nuxt to 3.21.10 or later

Other vulnerabilities in nuxt