GHSA-RQ7W-G337-39QQ: Project Directory Path and Workspace UUID Disclosure in Nuxt Dev Server

The Nuxt framework development environment spins up a local server using the Nitro engine to facilitate rapid prototyping and hot module replacement. To integrate with browser developer tools, Nuxt automatically implements an endpoint at the standard path /.well-known/appspecific/com.chrome.devtools.json. This endpoint facilitates Chrome DevTools Workspaces, allowing real-time synchronization between the browser's console and the local filesystem source code.\n\nIn vulnerable versions of Nuxt, this configuration route was registered directly without any security checks. It exposes the project's root directory path on the local filesystem and a unique, persistent workspace identifier. The endpoint serves this highly sensitive data to any network client capable of making a successful HTTP GET request to the development port.\n\nThe vulnerability is classified as an improper input validation and access control issue, mapping to CWE-200 (Exposure of Sensitive Information to an Unauthorized Actor). It represents an exposure of internal system configurations to untrusted actors on the local area network or malicious third-party websites. The primary attack surfaces include cross-origin requests executed via DNS rebinding and direct probing over local networks.

The underlying flaw resides in how Nuxt configures and registers the Chrome DevTools integration handler. The Nitro server engine registers dev handlers through a pipeline designed to host utility endpoints. In affected releases, the handler for the com.chrome.devtools.json route returned the configuration payload directly, omitting any checks on the incoming HTTP request.\n\nThe server did not implement origin, referer, or host header verification before responding to requests. Consequently, any HTTP client that addressed the server's port could retrieve the sensitive JSON object. This behavior violates standard browser security assumptions regarding local development ports, which are typically assumed to be isolated from remote web origins.\n\nUnder normal conditions, browsers enforce the Same-Origin Policy (SOP) to block cross-origin reads. However, because the server did not validate the HTTP Host header, it remained fully susceptible to DNS rebinding techniques. Furthermore, if the server bound to all interfaces (using 0.0.0.0), any host on the same local network could access the endpoint directly without triggering cross-origin protections.

To understand the technical implementation, it is necessary to examine the original implementation within packages/nitro-server/src/index.ts. The handler was declared as a simple, unconditional event responder that returned the directory and project configuration.\n\ntypescript\n// Vulnerable Code Pattern\nnitro.options.devHandlers.push({\n route: '/.well-known/appspecific/com.chrome.devtools.json',\n handler: defineEventHandler(() => ({\n workspace: {\n ...projectConfiguration,\n root: nuxt.options.rootDir,\n },\n })),\n})\n\n\nThe pull request #35201 resolved this by inserting an authorization check. This validation relies on a new helper function named isLocalDevRequest. The function tests the incoming request's metadata before returning the payload, falling back to a 403 Forbidden status if the check fails.\n\ntypescript\n// Patched Code Pattern\nnitro.options.devHandlers.push({\n route: '/.well-known/appspecific/com.chrome.devtools.json',\n handler: defineEventHandler((event) => {\n if (!isLocalDevRequest(event, getDevHandlerAllowedHosts(nuxt))) {\n setResponseStatus(event, 403)\n return 'Forbidden'\n }\n return {\n workspace: {\n ...projectConfiguration,\n root: nuxt.options.rootDir,\n },\n }\n }),\n})\n\n\nThe patch introduces a helper isLocalDevRequest which parses the host header, the sec-fetch-site header, and fallback origin or referer headers. The primary verification checks if the request's host matches loopback IPs or explicitly allowed hosts configured in Vite. It also uses the sec-fetch-site header to ensure the request is same-origin or initiated directly by the user (none).\n\nThere is a minor limitation in the host parser: const host = hostHeader?.split(':')[0]. For IPv6 addresses containing ports, such as [::1]:3000, splitting on the colon splits the address itself. This causes the host to be evaluated as [ which fails the loopback validation check and generates a 403 error for legitimate local IPv6 requests.\n\nmermaid\ngraph LR\n subgraph Client [Browser Context]\n A["Malicious Page"] -->|1. Fetch Request| B["Localhost Dev Server"]\n end\n subgraph Nuxt [Vulnerable Dev Server]\n B -->|2. Route Handler| C["com.chrome.devtools.json"]\n C -->|3. Discloses| D["Absolute Root Path & UUID"]\n D -->|4. Exfiltrated Data| A\n end\n

Exploitation requires that an attacker establish a vector to reach the development port, typically 3000, on the developer's local machine. Under a DNS rebinding attack, the target developer is enticed to visit a malicious domain controlled by the attacker. The attacker's domain is configured with a very low Time-To-Live (TTL) value to facilitate rapid IP changes.\n\nOnce the page loads, the attacker's DNS server updates its resolution to point to 127.0.0.1. The browser, believing it is communicating with the original domain, issues an asynchronous HTTP request to the development port. Because the browser treats this request as same-origin with the malicious page, the script can bypass standard SOP and read the JSON response.\n\nAlternatively, if the developer binds the server to 0.0.0.0, the endpoint is exposed directly to the local subnet. Any malicious device on the same local network can perform a direct HTTP GET request to retrieve the data. In this scenario, no browser-based interaction is required to successfully extract the information.\n\nbash\n# LAN-based data extraction command\ncurl -s http://192.168.1.50:3000/.well-known/appspecific/com.chrome.devtools.json\n

The exposure of the absolute filesystem path reveals local system details. This disclosure provides information such as local usernames, home directory structures, and naming conventions of internal development projects. For example, a response revealing /Users/restricted_dev/internal-projects/proprietary-finance leaks the precise organizational environment.\n\nThe exposure of the persistent workspace UUID represents a secondary security risk. This identifier remains constant across development sessions, allowing attackers to perform persistent tracking and fingerprinting of a specific developer's machine. This identifier could also be abused to target internal APIs exposed by browser extensions or IDE integrations that rely on the workspace configuration.\n\nWhile the vulnerability does not directly lead to remote code execution on its own, it functions as a critical reconnaissance step. Attackers can combine filesystem layout information with other local vulnerabilities, such as local file inclusion or directory traversal, to construct targeted exploit chains. The absence of validation on developer-facing local endpoints remains a significant threat vector.

The primary mitigation strategy is upgrading the project's Nuxt dependencies to a version incorporating the fix from Pull Request #35201. This introduces the host validation mechanism and rejects unauthorized requests with a 403 status code. Developers should execute a clean package installation to ensure the patch is applied to the active node_modules environment.\n\nIf immediate upgrading is not possible, developers should ensure the development server is strictly bound to the loopback interface (127.0.0.1 or ::1). Binding to wildcard interfaces like 0.0.0.0 or --host should be avoided unless strictly necessary and conducted within an isolated network. Using containers can also isolate the host filesystem and mitigate directory disclosures.\n\nDevelopers can manually verify their exposure using network tools. Sending a modified Host header to the local server simulates a DNS rebinding attempt. If the server returns a 403 Forbidden status, the mitigation is active; a 200 OK status indicates the development server remains vulnerable.\n\nbash\n# Verification command simulating a rebinding host\ncurl -I -H "Host: rogue-domain.com" http://localhost:3000/.well-known/appspecific/com.chrome.devtools.json\n