GHSA-7c4v-fwgw-9rf7: Nuxt Dev Server Discloses Project Root and Workspace UUID via Chrome DevTools Endpoint

Nuxt is an open-source framework built on Vue.js that simplifies modern web application development. During local development, developers initiate the Nuxt development server, typically executed via the nuxt dev command. To streamline debugging and optimize browser-based workflows, the development server exposes specialized internal endpoints. These endpoints facilitate integration with external tools such as Chrome DevTools.

One such endpoint is located at the static path /.well-known/appspecific/com.chrome.devtools.json. This endpoint is designed to automate file mapping and support workspace integration within Chrome DevTools. By default, the endpoint exposes highly sensitive host metadata, including the absolute path of the project on the developer's filesystem and a persistent workspace identifier.

While this feature is intended to support local development, exposing these details introduces a security risk if the endpoint is accessible to unauthorized actors. This vulnerability, categorized under GHSA-7c4v-fwgw-9rf7 and mapped to CWE-200, emerges when a developer binds the dev server to a network-reachable interface. This configuration permits adjacent network actors to bypass header-based filters and retrieve local environment configurations without authentication.

The root cause of this vulnerability lies in the reliance on application-layer HTTP headers to establish the source and authorization of an incoming connection. To protect the com.chrome.devtools.json endpoint from cross-origin attacks, such as Cross-Site Request Forgery (CSRF) or DNS rebinding, Nuxt deployed a verification helper named isLocalDevRequest.

This utility analyzed HTTP metadata supplied by the user-agent, examining the Sec-Fetch-Site, Origin, and Referer headers. If these browser-specific headers were missing, the server assumed that the transaction did not originate from a web browser. In such scenarios, the logic concluded that a cross-site request was impossible, and subsequently defaulted to assessing the request based on the Host header.

However, HTTP headers are arbitrary strings that can be configured by any non-browser client, such as a command-line utility or a custom script. If a developer runs the development server with the --host flag to permit external testing on a mobile device or virtual machine, the server binds to 0.0.0.0 or a local subnet IP address. Under these conditions, an attacker on the same Local Area Network (LAN) can send a direct socket-level connection to the development server. By manually populating the Host header with a permitted value like localhost, the validation logic is successfully bypassed.

The vulnerability was addressed by migrating the primary trust decision from forgeable HTTP application-layer headers to the transport-layer properties of the underlying TCP socket. The patch introduces a validation utility that evaluates the actual network interface of the incoming peer.

The fix establishes a dual-layer check, requiring both a genuine local peer loopback address and the traditional header check. Below is the implemented validation code located in packages/nitro-server/src/dev-request.ts:

// Normalizes and validates loopback ranges to prevent external access
export function isLoopbackAddress (address: string | undefined | null): boolean {
  if (!address) {
    return false
  }
  let normalized = address.trim().toLowerCase().replace(/^\\[/, '').replace(/\\]$/, '')
  
  // Remove IPv6 zone identifier, if present (e.g., fe80::1%eth0)
  const zoneIndex = normalized.indexOf('%')
  if (zoneIndex !== -1) {
    normalized = normalized.slice(0, zoneIndex)
  }
  
  // Handle IPv4-mapped IPv6 addresses (e.g., ::ffff:127.0.0.1)
  if (normalized.startsWith('::ffff:')) {
    normalized = normalized.slice('::ffff:'.length)
  }
  
  if (normalized === '::1') {
    return true
  }
  
  // Match standard IPv4 loopback range (127.0.0.0/8)
  return /^127\\.\\d{1,3}\\.\\d{1,3}\\.\\d{1,3}$/.test(normalized)
}
 
export function isLoopbackPeer (event: H3Event): boolean {
  // Accesses the raw socket properties directly, bypassing proxies and spoofed headers
  return isLoopbackAddress(getRequestIP(event))
}

In packages/nitro-server/src/index.ts, the endpoint handler enforces this constraint prior to delivering the workspace configuration payload:

// Require a genuine loopback peer to prevent remote extraction
if (!isLoopbackPeer(event) || !isLocalDevRequest(event, getDevHandlerAllowedHosts(nuxt))) {
  setResponseStatus(event, 403)
  return 'Forbidden'
}

By retrieving the IP directly via socket-level attributes, the application removes the possibility of a spoofed X-Forwarded-For or Host header bypassing the validation boundary. Non-loopback clients are immediately rejected with a 403 Forbidden status.

To execute an exploit against this endpoint, an attacker must first satisfy several environmental constraints. The target Nuxt application must be actively running in development mode. Additionally, the development server must be configured to listen on external network interfaces. This occurs when executing nuxt dev --host or specifying host settings like 0.0.0.0 or a specific LAN IP in the configuration file.

The attacker must occupy a network position capable of routing TCP traffic to the developer's workstation, such as being connected to the same local area network or wireless access point. Once these criteria are met, the attacker can initiate a crafted HTTP request.

A typical exploit payload can be sent using a standard command-line HTTP utility. The attacker explicitly overrides the Host header to emulate a local connection while targeting the workstation's external LAN IP:

curl -H "Host: localhost" http://<WORKSTATION_LAN_IP>:3000/.well-known/appspecific/com.chrome.devtools.json

Upon receiving this request, the vulnerable server identifies the absence of browser-related metadata (such as Sec-Fetch-Site or Origin). The application relies solely on the fake Host: localhost parameter, verifies it against the authorized host whitelist, and exposes the JSON payload containing the absolute local folder path and workspace UUID.

The security impact of GHSA-7c4v-fwgw-9rf7 is classified as Medium, with a CVSS v4.0 base score of 5.3. Because the vulnerability is confined to the development server handlers, it cannot be leveraged to compromise production builds. Production deployment pipelines compile Nuxt into optimized assets where development-only utility routes are absent.

While Remote Code Execution (RCE) or arbitrary file modifications are not achievable through this vulnerability, the disclosure of the absolute project path exposes the local user directory structure of the developer's workstation. This information can be integrated into multi-stage attack chains to map target filesystems or identify specific user accounts.

The workspace UUID returned by the endpoint represents a persistent identifier. In scenarios where tracking or profiling developer environments is of value, this identifier can be logged to correlate the developer across different sessions and development contexts. Consequently, this vulnerability represents an information disclosure threat targeting developer workstations within shared network environments.

Remediation requires upgrading the Nuxt package to a patched release. For projects running the Nuxt v3 line, the dependency must be updated to version 3.21.10 or higher. For applications running Nuxt v4, the dependency must be upgraded to version 4.5.1 or higher.

If upgrading is not immediately possible, developers can implement mitigations to secure their environment. The most effective mitigation is to restrict the development server's binding configuration to the local loopback interface. Developers should avoid specifying --host or 0.0.0.0 inside public or untrusted local networks, such as public Wi-Fi access points.

Alternatively, the experimental integration feature can be explicitly disabled within the project configuration. Modifying nuxt.config.ts or nuxt.config.js to set experimental.chromeDevtoolsProjectSettings to false removes the registration of the vulnerable endpoint:

export default defineNuxtConfig({
  experimental: {
    chromeDevtoolsProjectSettings: false
  }
})

Finally, host-based firewalls (such as ufw on Linux or Windows Defender Firewall) can be configured to block incoming external TCP traffic destined for local development ports, guaranteeing that only the loopback interface can initiate connections.