CVE-2026-44372

Nitro is a next generation server toolkit. Prior to 3.0.260429-beta, an attacker could turn a redirect route rule using wildcards rewrite into a cross-host redirect by sliding an extra slash in after the rule prefix. This vulnerability is fixed in 3.0.260429-beta.

Nitro is a next generation server toolkit. Prior to 3.0.260429-beta, an attacker could turn a redirect route rule using wildcards rewrite into a cross-host redirect by sliding an extra slash in after the rule prefix. This vulnerability is fixed in 3.0.260429-beta.

A redirect route rule like:

routeRules: {
  "/legacy/**": { redirect: "/**" }
}

is intended to rewrite paths within the same host. Before the patch, an attacker could turn the rewrite into a cross-host redirect by sliding an extra slash in after the rule prefix. Example exploit:

GET /legacy//evil.com

Nitro stripped /legacy from the matched pathname and joined the remainder against the rule's target. The remainder was //evil.com, which the join preserved verbatim, so Nitro responded with Location: //evil.com. Browsers resolve //evil.com as a protocol-relative URL against the current scheme, sending the user to https://evil.com.

Are you affected?

Users may be affected if all of the following are true:

1. Their project uses Nitro's routeRules with a redirect entry.
2. The target uses a /** wildcard suffix to forward sub-paths (e.g. redirect: "/**", redirect: "/new/**", proxy: { to: "http://upstream/**" }).
3. The redirect rule is not handled natively at the CDN layer. The vercel, netlify, cloudflare-pages, and edgeone presets translate routeRules.redirect into platform config (vercel.json, _redirects, EdgeOne v3 config) and serve the redirect at the edge — those deployments bypass the Nitro runtime entirely and are not affected. Every other preset executes the redirect through the Nitro runtime and can be vulnerable.

Impact

Open redirect from any host serving Nitro with a wildcard redirect rule. The redirect target is fully attacker-controlled, the URL looks legitimate (it starts with the victim's domain), and the browser silently follows it.

Patched versions

Upgrade to one of:

• 2.13.4 or later (or upgrade lockfile with latest ufo 1.6.4+)
• 3.0.260429-beta or later (https://github.com/nitrojs/nitro/pull/4236)

The fix has two parts:

1. ufo is bumped to ^1.6.4 (unjs/ufo@5cd9e67), which collapses any run of leading slashes to a single / inside withoutBase. This covers the typical "/scope/**" rule.
2. The Nitro runtime additionally collapses leading // before joining when the rule path itself is /** (in rare case which case withoutBase is never called and the raw pathname flows straight into joinURL("", …)).

Summary

When running nuxt dev, Nuxt registers an unauthenticated route at /.well-known/appspecific/com.chrome.devtools.json that returns the absolute filesystem path of the project root and a per-project UUID persisted to node_modules/.cache/nuxt/chrome-workspace.json. The route is enabled by default via experimental.chromeDevtoolsProjectSettings: true.

The endpoint exists to let Chrome DevTools' Workspace integration map sources to the developer's local checkout. The handler is registered directly on nitro.options.devHandlers and does not pass through the CORS / origin wrapper that the rest of the dev pipeline uses, so it has no host / origin / Sec-Fetch-Site check of its own.

Impact

Dev-server only. Production builds do not register the route.

Two values are disclosed:

• workspace.root: the absolute filesystem path of the project (commonly reveals the OS username and the on-disk project name).
• workspace.uuid: a v4 UUID persisted to node_modules/.cache/nuxt/chrome-workspace.json, stable across dev-server restarts and re-clones.

Threat model

The response carries no Access-Control-Allow-Origin header. A cross-origin fetch() from an arbitrary malicious page is therefore blocked by the browser's same-origin policy and cannot read the body. The two realistic recovery paths are:

1. LAN-adjacent attacker when the developer runs nuxt dev --host (or otherwise binds to a non-loopback interface). A plain curl http://<dev-lan-ip>:3000/.well-known/appspecific/com.chrome.devtools.json returns the JSON; no browser, no CORS.
2. DNS rebinding against the default loopback dev server. A page the developer visits resolves to the attacker, then re-resolves to 127.0.0.1 after the TTL; the browser believes the request is same-origin and reads the response.

Affected versions

[email protected] (PR #32084) through [email protected]. 3.x is not affected.

Reproduction

npx nuxt dev
curl -s http://localhost:3000/.well-known/appspecific/com.chrome.devtools.json
# {"workspace":{"uuid":"...","root":"/Users/<name>/..."}}

Workaround

Set experimental: { chromeDevtoolsProjectSettings: false } in nuxt.config.ts. Chrome DevTools' Workspace auto-integration will stop working; the dev server is otherwise unaffected.

Patches

Fixed in [email protected] by #35201 (commit 55c75b78). The handler is now routed through the same host / origin gate the rest of the dev server uses, so the endpoint only responds to requests that look local.

Nitro is a next generation server toolkit. Prior to 3.0.260429-beta, an attacker could turn a redirect route rule using wildcards rewrite into a cross-host redirect by sliding an extra slash in after the rule prefix. This vulnerability is fixed in 3.0.260429-beta.

Nitro is a next generation server toolkit. Prior to 3.0.260429-beta, an attacker could turn a redirect route rule using wildcards rewrite into a cross-host redirect by sliding an extra slash in after the rule prefix. This vulnerability is fixed in 3.0.260429-beta.