Threat Intelligence Database

## Duplicate Advisory This advisory has been withdrawn because it is a duplicate of GHSA-7c4v-fwgw-9rf7. This link is maintained to preserve external references. ## Original Description Nuxt versions >= 4.4.7 and < 4.5.1, and >= 3.21.7 and < 3.21.10, contain an information disclosure vulnerability in the development server's Chrome DevTools workspace endpoint (GET /.well-known/appspecific/com.chrome.devtools.json). The endpoint's local-request gate (isLocalDevRequest) is header-based and trusts the attacker-supplied Host header rather than the connected peer address. When the dev server is bound to a network-reachable interface (e.g. nuxt dev --host) and experimental.chromeDevtoolsProjectSettings is enabled (the default), an unauthenticated attacker on the LAN can send a request with a spoofed Host header and no browser-specific headers (Sec-Fetch-Site, Origin, Referer) to retrieve the project's absolute filesystem root path (rootDir) and a persistent per-project workspace UUID. Production builds are unaffected. Fixed in 4.5.1 and 3.21.10.

### Impact 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. ### Patches 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). ### 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`.

Nuxt versions 4.0.0 before 4.4.7 and 3.18.0 before 3.21.7 have a vulnerability in the development server on Linux where the vite-node IPC server binds to an abstract-namespace Unix socket without permission restrictions. This allows local unprivileged users to connect to the socket and potentially read sensitive files such as .env and SSH keys through the SSR plugin pipeline. Production builds are not affected as this IPC server runs only in development mode.

Nuxt versions prior to 4.4.7 and 3.21.7 contain a reflected DOM-based cross-site scripting (XSS) vulnerability in the <NuxtLink> component. This occurs because the component does not validate URL schemes in its 'to' or 'href' props, allowing attacker-controlled inputs with 'javascript:', 'vbscript:', or 'data:' URLs to be rendered directly into anchor href attributes. Clicking such links can execute malicious scripts in the application's origin or enable phishing attacks. The issue affects applications that bind user input to <NuxtLink> URLs, such as user profiles, CMS fields, or marketplace listings. The vulnerability is fixed in [email protected] and [email protected] by sanitizing and rejecting script-capable URL schemes before rendering.

CVE-2026-56301 is a medium severity vulnerability in Nuxt's development server on Linux when running with Node.js 20 or higher outside containerized environments. The internal vite-node IPC server binds to an abstract-namespace Unix socket without permission restrictions, allowing any local user who can read /proc/net/unix to connect. This enables unauthorized local users to read sensitive files from the developer's environment via SSR plugin requests. The issue affects only development mode (nuxt dev) on shared multi-tenant Linux hosts and not production builds or containerized environments. The vulnerability is fixed in Nuxt versions 4.4.7 and 3.21.7 by switching to a filesystem socket with restricted permissions.

Three URL-handling weaknesses in Nuxt's client-navigation APIs (`navigateTo` and `reloadNuxtApp`) allow SSR open redirects, client-side script execution, and protocol-relative bypasses. These vulnerabilities can lead to phishing, OAuth token theft, or reflected XSS if user-controlled input is passed unsafely. Fixed in nuxt versions 4.4.7 and 3.21.7.