CVE-2026-41305

What it actually does

PostCSS versions before 8.5.10 incorrectly stringify CSS Abstract Syntax Trees without escaping literal </style> sequences. If an application accepts user-controlled CSS, processes it through PostCSS, and then embeds the resulting CSS directly inside an HTML <style> element, an attacker can terminate the style block early and inject attacker-controlled HTML or JavaScript. The result is a stored or reflected cross-site scripting condition in the consuming application, depending on where the CSS input is stored and rendered. The CVSS scope change reflects that successful exploitation can cause attacker-controlled script execution in a victim user's browser under the vulnerable application's origin.

Why it matters to the business

An affected application may allow attackers to run JavaScript in users' browsers, which can lead to account takeover, unauthorized actions performed as the victim, theft of session-related data accessible to scripts, defacement, phishing overlays, or manipulation of application content. Because PostCSS is a widely used CSS processing library and this issue can exist indirectly through build tools, CMS features, design editors, profile customization, email/template rendering, or theme systems, organizations should assess both direct and transitive dependency exposure. The current EPSS score is low and the issue is not listed in CISA KEV, but the bug is straightforward to trigger where user-supplied CSS is embedded into HTML style tags, so internet-facing features that accept custom CSS should be prioritized.

How an attack unfolds

An attacker first identifies a feature that accepts CSS or CSS-like values, such as custom themes, profile styling, page builders, rich content editors, email templates, or administrative branding settings. They submit CSS containing a value with a literal </style> sequence followed by malicious HTML or JavaScript, for example a script tag or an element with an event handler. The application parses and re-stringifies that CSS through a vulnerable PostCSS version. Because the vulnerable version does not escape the closing style tag sequence, the generated CSS remains syntactically capable of closing the surrounding HTML <style> element. When the application later embeds the processed CSS into an HTML page, the browser exits the style context and interprets the attacker-controlled content as HTML/JavaScript. When a victim views the affected page, the injected script executes in the context of the vulnerable site and can perform actions available to that user, read non-HttpOnly page data, alter displayed content, or send data to attacker-controlled infrastructure.

How to fix it

Upgrade PostCSS to version 8.5.10 or later everywhere it is used, including transitive dependency paths in frontend build tooling, server-side rendering, CMS/theme pipelines, template processors, email generation workflows, and any service that accepts or renders user-controlled CSS. Regenerate lockfiles and rebuild artifacts so deployed applications actually consume the patched package. If immediate upgrade is not possible, avoid embedding user-submitted or dynamically generated CSS directly inside HTML <style> tags; instead place CSS in separate files served with the correct Content-Type, strictly sanitize or reject </style and equivalent encoded forms in user-controllable CSS, and apply context-appropriate output encoding before insertion into HTML. Add or strengthen a Content Security Policy that blocks inline script execution where feasible, but do not treat CSP as a complete fix because the vulnerable rendering behavior remains present. Review features that allow custom CSS and restrict them to trusted users until patched.

How to confirm the fix worked

Confirm dependency resolution shows PostCSS 8.5.10 or later in every deployed application and build/runtime package graph. For Node.js projects, inspect package-lock.json, npm-shrinkwrap.json, yarn.lock, pnpm-lock.yaml, and software composition analysis output for postcss versions below 8.5.10. Run package-manager checks such as npm ls postcss, yarn why postcss, or pnpm why postcss from relevant application roots. Validate deployed artifacts, not only source repositories, because vulnerable generated bundles or server-side renderers may persist after dependency updates. As a functional test in a non-production environment, submit benign CSS containing a closing style sequence followed by harmless marker HTML and verify the rendered page does not break out of the style context or execute markup. Confirm that user-controlled CSS is either escaped, sanitized, rejected, or delivered outside inline style tags.

Typical attack path

1. Find an application feature that accepts user-controlled CSS or design/theme input.
2. Submit CSS containing a </style> sequence followed by attacker-controlled HTML or JavaScript payload content.
3. Rely on the application to parse and stringify the CSS using PostCSS before version 8.5.10.
4. Cause the processed CSS to be embedded inside an HTML <style> tag without additional contextual escaping or sanitization.
5. Wait for a victim user to view the rendered page containing the processed CSS.
6. Execute JavaScript in the victim's browser under the vulnerable application's origin.
7. Use the browser execution context to steal accessible data, perform unauthorized actions, alter page content, or deliver follow-on phishing content.

How to detect it

To determine whether exploitation has already occurred, review any place where user-controlled CSS, themes, templates, rich editor content, page-builder blocks, profile styling, or branding configuration is stored or logged. Search application logs, WAF logs, CDN logs, reverse proxy logs, API request bodies, moderation queues, database exports of user-generated styling content, and audit logs for closing style tag sequences followed by HTML or JavaScript constructs. Focus on payloads containing </style> followed by <script, <img, <svg, <iframe, event-handler attributes such as onerror= or onload=, javascript: URLs, or external callback domains. Check rendered content stores for suspicious injected markup that appears outside expected CSS fields. Browser-side telemetry, CSP violation reports, and EDR/network logs may show unexpected requests to attacker-controlled domains immediately after users load pages containing custom CSS. If administrative users or privileged editors viewed affected pages, review account activity after page views for unusual changes, new API tokens, password or MFA changes, suspicious exports, privilege changes, or unauthorized configuration updates. Because this is an application-library XSS issue, there may be no single product-specific artifact; detection depends on finding malicious CSS input and correlating it with rendered page views and subsequent suspicious browser or account activity.

• </style><script
• </style> <script
• </style><img
• </style> <img
• </style><svg
• </style> <svg
• </style><iframe
• </style> <iframe
• </style><body
• </style><div
• </style><a
• %3C%2Fstyle%3E%3Cscript
• %3c%2fstyle%3e%3cscript
• %3C/style%3E%3Cscript
• \u003c/style\u003e
• \x3c/style\x3e
• </style><script>alert(
• </style><script src=
• </style><img src=x onerror=
• </style><svg onload=
• </style><iframe src=
• </style><a href=javascript:
• onerror=
• onload=
• javascript:

What your security team should do

• Inventory all applications and build pipelines that use PostCSS directly or through frontend frameworks, bundlers, CMS plugins, design systems, or CSS optimization tools.
• Prioritize patching internet-facing applications and any feature that accepts custom CSS, themes, branding, page-builder content, templates, or user-generated styles.
• Upgrade PostCSS to 8.5.10 or later, regenerate lockfiles, rebuild assets, and redeploy affected services.
• Search source code and templates for patterns that embed processed CSS inside <style> tags, especially when the CSS originates from users, tenants, editors, administrators, or external feeds.
• Temporarily disable or restrict untrusted custom CSS submission until all affected rendering paths are patched and validated.
• Add server-side validation to reject literal and encoded closing style tag sequences in user-controllable CSS where business requirements allow.
• Deploy or tighten Content Security Policy controls to reduce the impact of successful XSS, including avoiding unsafe-inline script execution where possible.
• Review logs and stored content for historical payloads containing </style> followed by script tags, event handlers, iframes, SVG payloads, or external network callbacks.
• Ensure SCA and CI/CD dependency scanning fail builds that resolve PostCSS below 8.5.10.
• Because the issue is not currently in KEV and EPSS is low, treat this as prioritized hygiene unless exposed custom-CSS functionality is public or unauthenticated, in which case treat it as urgent.