CVE-2026-49993: Proprietary Source Code Exfiltration via Incomplete Same-Origin Verification in Nuxt Dev Servers

Nuxt local development environments leverage hot reloading and build asset transmission, requiring the development server to host compiled source assets. To prevent malicious websites from reading these local builder chunks via cross-origin fetch requests, same-origin verification checks are implemented.

CVE-2026-49993 is an information disclosure vulnerability within the @nuxt/webpack-builder and @nuxt/rspack-builder modules. This flaw permits remote attackers to bypass same-origin checks and exfiltrate proprietary source code.

The vulnerability exists as an incomplete remediation of GHSA-6m52-m754-pw2g and GHSA-4gf7-ff8x-hq99. When the dev server is bound to a non-loopback address, a malicious website can craft a headerless request that bypasses validation.

The same-origin validation mechanism (isSameOriginRequest) includes a fallback branch to permit headerless requests. This fallback exists to support developer utility tools like curl and local hot module replacement processes that do not transmit browser-specific security headers.

If the validation headers Sec-Fetch-Site, Origin, and Referer are completely absent, the middleware assumes the request originates from a trusted non-browser client. An attacker can manipulate web standard behaviors to coerce a victim's browser into stripping these headers during a cross-origin request.

Standard browser behaviors omit Sec-Fetch-Site when communicating with plain HTTP targets on a physical LAN. The Origin header is dropped during standard, non-CORS script subresource fetches, while the Referer header is suppressed using a no-referrer policy.

In the vulnerable implementation, the same-origin validation utility allowed requests instantly if both the origin and referrer headers were absent. The middleware evaluated if (!initiator) return true; without verifying the host binding configuration.

The corrected implementation introduces a host validation routine isLoopbackHost to check if the incoming Host header corresponds to a local loopback address. If the initiator is absent, the middleware now returns the result of this loopback validation.

// Patch implemented in Pull Request #35200
const LOOPBACK_HOSTNAMES = new Set(['localhost', '127.0.0.1', '::1'])
 
function isLoopbackHost (host: string | undefined): boolean {
  if (!host) { return false }
  const withoutPort = host.replace(/:\d+$/, '')
  const hostname = withoutPort.replace(/^\([|]\)$/g, '').toLowerCase()
  return LOOPBACK_HOSTNAMES.has(hostname)
}
 
export function isSameOriginRequest (req: { headers: Record<string, string | string[] | undefined> }): boolean {
  const site = firstHeader(req.headers['sec-fetch-site'])
  if (site !== undefined) {
    return site === 'same-origin' || site === 'none'
  }
 
  const initiator = firstHeader(req.headers.origin) || firstHeader(req.headers.referer)
  if (!initiator) {
    // Only allow header-less requests if bound to loopback
    return isLoopbackHost(firstHeader(req.headers.host))
  }
 
  try {
    return new URL(initiator).host === firstHeader(req.headers.host)
  } catch {
    return false
  }
}

The attack relies on a developer hosting their local Nuxt application bound to a non-loopback network interface. An attacker on the local network or a public web resource targets the developer's LAN-exposed dev server IP address.

The attacker lures the developer to a malicious site that initiates a cross-origin script load. By setting referrerpolicy="no-referrer" on the script tag and requesting the main JavaScript entry point from the LAN IP, the browser suppresses all validation headers.

When the browser executes the loaded chunk, the malicious parent page executes introspection techniques against the global Webpack or Rspack registry. The payload serializes the loaded components via Function.prototype.toString() and exfiltrates the source code to a remote endpoint.

A successful exploit allows the complete exfiltration of proprietary client-side and server-side source code compiled during the dev session. Attackers gain access to structural configuration details, application logic, and potentially embedded hardcoded credentials.

The CVSS v3.1 score is evaluated at 5.7, indicating a medium severity rating. This reflects the requirement for user interaction and network adjacency, despite the high confidentiality compromise.

Since this is an unauthenticated client-side exfiltration vector, it operates as a silent attack mechanism. The victim developer is not notified of the memory introspection and subsequent transmission of the source code assets.

The primary resolution requires upgrading the @nuxt/webpack-builder and @nuxt/rspack-builder dependencies. The framework maintainers patched this issue in versions 3.21.7 and 4.4.7.

When upgrading is not feasible, developers must avoid binding development instances to non-loopback interfaces. Running servers via nuxt dev --host exposes the application to adjacent network threats and headerless exploitation.

Additional protection is achieved by leveraging browser profiles that enforce strict Local Network Access (LNA) validation. Isolating development sessions from general web browsing limits the exposure of local ports to external websites.