Nuxt from 4.6.0 before 4.6.2 contains a route parameter confusion vulnerability in getRouterParam and getRouterParams that lets attackers return a parameter value different from the one h3 matched by sending paths containing an encoded question mark (%3F). Attackers can craft requests where authorization checks use the Nuxt helper value while resource selection uses event.context.params, allowing access to unauthorized resources.
A path normalization vulnerability in Nuxt versions 4.6.0 through 4.6.2 allows bypassing server-side middleware and route rules by using dot segments ('.' and '..') or their percent-encoded forms in request paths. This causes the page router to resolve these segments before rendering, while server-side checks see the unnormalized path, enabling unauthorized access to protected pages. The issue is fixed in Nuxt 4.6.3, which returns 404 for such paths and normalizes route rule keys accordingly.
## 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 `nuxt@4.5.1` and `nuxt@3.21.10`. 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.
CVE-2026-56317 is a cross-site scripting (XSS) vulnerability in Nuxt versions before 4.4.7 and 3.x versions before 3.21.7. The issue exists in the NoScript component, which writes slot content to innerHTML without proper escaping. This allows attackers to inject malicious scripts via untrusted data, such as route.query parameters, which execute in the document context when the noscript tag is implicitly closed by script tags.
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 nuxt@4.4.7 and nuxt@3.21.7 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.