CVE-2026-41305

PostCSS takes a CSS file and provides an API to analyze and modify its rules by transforming the rules into an Abstract Syntax Tree. Versions prior to 8.5.10 do not escape </style> sequences when stringifying CSS ASTs. When user-submitted CSS is parsed and re-stringified for embedding in HTML <style> tags, </style> in CSS values breaks out of the style context, enabling XSS. Version 8.5.10 fixes the issue.

Nuxt versions 4.0.0 before 4.4.7 and 3.x before 3.21.7 contain a server-side open redirect vulnerability in navigateTo that fails to properly validate path-normalized payloads like /..//evil.com and /.//evil.com. Attackers can bypass external-host checks using path-normalization techniques to redirect users to attacker-controlled sites via the Location header or meta-refresh, enabling phishing and OAuth authorization-code theft.

Nuxt versions 4.0.0 before 4.4.7 and 3.x before 3.21.7 accept protocol-relative paths such as //evil.com in the reloadNuxtApp function; these pass the script-protocol check but resolve to a cross-origin URL against the current page protocol. Attackers can inject paths like //evil.com to redirect users to attacker-controlled hosts, enabling phishing and OAuth authorization-code theft.

Nuxt versions 4.0.0 before 4.4.7 and 3.x before 3.21.7 fail to validate script-capable URLs in the navigateTo open option, allowing client-side script execution. Attackers can supply javascript: URLs through the open parameter to execute arbitrary scripts in the application's origin when user-controlled input is passed to navigateTo.

PostCSS takes a CSS file and provides an API to analyze and modify its rules by transforming the rules into an Abstract Syntax Tree. Versions prior to 8.5.10 do not escape </style> sequences when stringifying CSS ASTs. When user-submitted CSS is parsed and re-stringified for embedding in HTML <style> tags, </style> in CSS values breaks out of the style context, enabling XSS. Version 8.5.10 fixes the issue.

Summary

Three weaknesses in Nuxt's client-navigation URL handling, all reachable from documented public APIs (navigateTo and reloadNuxtApp):

1. (CVE-2026-56326) SSR open redirect in navigateTo via path-normalisation bypass. navigateTo decided whether a target was external by inspecting the raw input with hasProtocol(..., { acceptRelative: true }). Inputs such as /..//evil.com, /.//evil.com, /%2e%2e//evil.com, or /app/..//evil.com slipped past that check because they start with /, but WHATWG URL parsing then normalised them to the protocol-relative pathname //evil.com. The normalised value was written to the Location response header and into the <meta http-equiv="refresh"> body of the SSR redirect page, so a victim's browser would resolve the redirect cross-origin to the attacker's host.

2. (CVE-2026-56698) Client-side script execution via navigateTo({ open: ... }). The client-side early-open handler called window.open(toPath, ...) without applying the isScriptProtocol check that gates the normal navigateTo path. A target of javascript:... (or another script-capable scheme) passed to navigateTo(url, { open: { ... } }) therefore executed in the application's origin instead of being rejected.

3. (CVE-2026-56697) Open redirect in reloadNuxtApp via protocol-relative bypass. reloadNuxtApp({ path }) rejects script-capable protocols by parsing the path with new URL(path, window.location.href) and checking the resolved protocol against isScriptProtocol. Protocol-relative paths such as //evil.com resolve to the current page's protocol (https:), which passes that check; the value is then assigned to window.location.href, which the browser treats as a cross-origin redirect. This is the same protocol-relative bypass family as (1), in a different sink.

Impact

For (1), the practical risk is phishing or OAuth-code theft against any Nuxt app that forwards user-controlled input (for example a ?next= query parameter on a login route) into navigateTo on the server. The framework documents that navigateTo blocks external hosts unless external: true is passed, so maintainers commonly rely on it as the safe path for post-login redirects.

For (2), any app that passes a user-controlled URL into navigateTo(url, { open: { ... } }) was vulnerable to reflected XSS in the application's first-party origin.

For (3), any app that forwards user-controlled input into reloadNuxtApp({ path }) could be redirected cross-origin for phishing or OAuth-code theft, even on releases that already shipped the isScriptProtocol guard added by #35115.

Patches

Fixed in [email protected] and backported to [email protected]. The three sinks are addressed by:

• Path-normalisation bypass in navigateTo:
  • 4.x: commit 2cce6fb0
  • 3.x: commit 1f2dd5e7
• navigateTo({ open }) script-protocol guard:
  • 4.x: #35206 (commit 3394716d)
  • 3.x: commit 62fc32ed
• Protocol-relative bypass in reloadNuxtApp:
  • 4.x: commit e447a793
  • 3.x: commit 6497d99d

Workarounds

• For (1): validate redirect targets before passing them to navigateTo, for example reject any input where new URL(target, 'http://localhost').pathname starts with //, or only accept a known allow-list of paths.
• For (2): reject any user-controlled URL whose protocol is…

PostCSS: XSS via Unescaped </style> in CSS Stringify Output

Summary

PostCSS v8.5.5 (latest) does not escape </style> sequences when stringifying CSS ASTs. When user-submitted CSS is parsed and re-stringified for embedding in HTML <style> tags, </style> in CSS values breaks out of the style context, enabling XSS.

Proof of Concept

const postcss = require('postcss');

// Parse user CSS and re-stringify for page embedding
const userCSS = 'body { content: "</style><script>alert(1)</script><style>"; }';
const ast = postcss.parse(userCSS);
const output = ast.toResult().css;
const html = `<style>${output}</style>`;

console.log(html);
// <style>body { content: "</style><script>alert(1)</script><style>"; }</style>
//
// Browser: </style> closes the style tag, <script> executes

Tested output (Node.js v22, postcss v8.5.5):

Input: body { content: "</style><script>alert(1)</script><style>"; }
Output: body { content: "</style><script>alert(1)</script><style>"; }
Contains </style>: true

Impact

Impact non-bundler use cases since bundlers for XSS on their own. Requires some PostCSS plugin to have malware code, which can inject XSS to website.

Suggested Fix

Escape </style in all stringified output values:

output = output.replace(/<\/(style)/gi, '<\\/$1');

Credits

Discovered and reported by Sunil Kumar (@TharVid)

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.

Root has patched CVE-2026-41305 in the postcss package for Root:npm. Multiple fixed versions available.

PostCSS takes a CSS file and provides an API to analyze and modify its rules by transforming the rules into an Abstract Syntax Tree. Versions prior to 8.5.10 do not escape </style> sequences when stringifying CSS ASTs. When user-submitted CSS is parsed and re-stringified for embedding in HTML <style> tags, </style> in CSS values breaks out of the style context, enabling XSS. Version 8.5.10 fixes the issue.

TuxCare rebuilt postcss to address 1 CVE. Fixed in 8.4.41-tuxcare.1.

TuxCare rebuilt postcss to address 2 CVEs. Fixed in 8.2.15-tuxcare.1.

TuxCare rebuilt postcss to address 1 CVE. Fixed in 8.4.31-tuxcare.1.

TuxCare rebuilt postcss to address 1 CVE. Fixed in 8.5.6-tuxcare.1.

TuxCare rebuilt postcss to address 2 CVEs. Fixed in 8.4.5-tuxcare.1.

TuxCare rebuilt postcss to address 4 CVEs. Fixed in 7.0.21-tuxcare.1.

TuxCare rebuilt postcss to address 4 CVEs. Fixed in 7.0.32-tuxcare.1.

TuxCare rebuilt postcss to address 4 CVEs. Fixed in 7.0.17-tuxcare.1.

TuxCare rebuilt nuxt to address 9 CVEs. Fixed in 4.0.3-tuxcare.4.

TuxCare rebuilt nuxt to address 1 CVE. Fixed in 3.12.3-tuxcare.3.

TuxCare rebuilt nuxt to address 2 CVEs. Fixed in 3.12.4-tuxcare.7.

TuxCare rebuilt nuxt to address 1 CVE. Fixed in 3.12.3-tuxcare.4.

TuxCare rebuilt postcss to address 2 CVEs. Fixed in 8.4.14-tuxcare.3.

TuxCare rebuilt postcss to address 6 CVEs. Fixed in 6.0.1-tuxcare.1.

TuxCare rebuilt postcss to address 4 CVEs. Fixed in 8.4.49-tuxcare.1.

TuxCare rebuilt postcss to address 1 CVE. Fixed in 8.5.2-tuxcare.3.

TuxCare rebuilt postcss to address 1 CVE. Fixed in 8.5.3-tuxcare.3.

TuxCare rebuilt postcss to address 3 CVEs. Fixed in 6.0.23-tuxcare.1.

TuxCare rebuilt @nuxt/vite-builder to address 10 CVEs. Fixed in 4.0.3-tuxcare.4.

TuxCare rebuilt @nuxt/webpack-builder to address 2 CVEs. Fixed in 3.12.4-tuxcare.7.

TuxCare rebuilt @nuxt/kit to address 10 CVEs. Fixed in 4.0.3-tuxcare.4.

TuxCare rebuilt @nuxt/kit to address 2 CVEs. Fixed in 3.12.4-tuxcare.7.

TuxCare rebuilt @nuxt/kit to address 1 CVE. Fixed in 3.12.3-tuxcare.4.

TuxCare rebuilt @nuxt/rspack-builder to address 10 CVEs. Fixed in 4.0.3-tuxcare.4.

TuxCare rebuilt @nuxt/schema to address 10 CVEs. Fixed in 4.0.3-tuxcare.4.

TuxCare rebuilt @nuxt/schema to address 2 CVEs. Fixed in 3.12.4-tuxcare.7.

TuxCare rebuilt @nuxt/schema to address 1 CVE. Fixed in 3.12.3-tuxcare.4.

TuxCare rebuilt @nuxt/vite-builder to address 2 CVEs. Fixed in 3.12.4-tuxcare.7.

TuxCare rebuilt @nuxt/vite-builder to address 1 CVE. Fixed in 3.12.3-tuxcare.4.

TuxCare rebuilt @nuxt/webpack-builder to address 10 CVEs. Fixed in 4.0.3-tuxcare.4.

TuxCare rebuilt @nuxt/webpack-builder to address 1 CVE. Fixed in 3.12.3-tuxcare.4.

TuxCare rebuilt postcss to address 1 CVE. Fixed in 8.5.5-tuxcare.2.

TuxCare rebuilt postcss to address 2 CVEs. Fixed in 8.2.9-tuxcare.3.

TuxCare rebuilt postcss to address 1 CVE. Fixed in 8.4.33-tuxcare.3.

TuxCare rebuilt postcss to address 1 CVE. Fixed in 8.4.17-tuxcare.3.