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.

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.

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.