CVE-2026-41240

What it actually does

CVE-2026-41240 is a DOMPurify sanitizer bypass that can allow HTML elements explicitly intended to be blocked by FORBID_TAGS to remain in sanitized output when an application uses function-based ADD_TAGS / EXTRA_ELEMENT_HANDLING logic. Because the FORBID_TAGS check can be skipped during short-circuit evaluation, forbidden elements may survive sanitization with their attributes intact. In applications that rely on DOMPurify to safely render untrusted HTML, SVG, or MathML, this can result in stored or reflected cross-site scripting depending on where attacker-controlled content is rendered and whether browser-executable markup survives downstream processing.

Why it matters to the business

Applications that allow users to submit rich text, HTML, SVG, MathML, comments, profiles, messages, documents, or embedded content may unintentionally render unsafe content in users’ browsers. Successful exploitation could let an attacker act within the victim’s browser session, steal sensitive page data, perform actions as the user, alter displayed content, or support phishing and account-takeover workflows. The current EPSS is low and there is no known KEV listing or ransomware association, but DOMPurify is widely used as a defensive dependency, so vulnerable versions can be present indirectly through frontend frameworks, CMS features, document editors, and downstream packages.

How an attack unfolds

An attacker first identifies an application path where user-supplied markup is accepted and later sanitized with DOMPurify before being inserted into the DOM. The attacker then crafts markup that relies on the application’s custom DOMPurify configuration, specifically configurations using function-based ADD_TAGS or EXTRA_ELEMENT_HANDLING while also expecting FORBID_TAGS to block dangerous or disallowed elements. Due to the sanitizer logic flaw, a tag that should have been rejected can pass through the tag handling path, and its attributes may remain intact. When another user views the affected content, the browser processes the surviving markup in the application’s trusted origin. If the markup can trigger script execution or unsafe browser behavior in that rendering context, the attacker gains cross-site scripting capabilities against the viewer.

How to fix it

Upgrade DOMPurify to version 3.4.0 or later wherever it is used, including direct frontend dependencies, bundled JavaScript assets, transitive dependencies, and server-side rendering pipelines that use DOMPurify with a DOM implementation. Rebuild and redeploy affected web assets after updating the package. Review any DOMPurify configurations that combine FORBID_TAGS with function-based ADD_TAGS, CUSTOM_ELEMENT_HANDLING, or EXTRA_ELEMENT_HANDLING, and ensure deny-list controls are not bypassed by custom allow logic. As defense in depth, use strict Content Security Policy controls that reduce the impact of XSS, avoid rendering sanitized HTML unless necessary, prefer structured rendering over raw HTML insertion, and apply contextual output encoding for non-HTML contexts.

How to confirm the fix worked

Confirm dependency resolution shows DOMPurify version 3.4.0 or later in package-lock.json, yarn.lock, pnpm-lock.yaml, shrinkwrap files, bundled asset manifests, and software composition analysis results. Verify built application bundles no longer contain vulnerable DOMPurify versions. Add regression tests for any sanitizer configuration using FORBID_TAGS together with function-based ADD_TAGS or EXTRA_ELEMENT_HANDLING to ensure forbidden tags are removed as expected. Test representative user-generated-content workflows and confirm previously forbidden elements do not survive sanitization. If using dependency scanners, rescan after rebuilding containers, static assets, and deployment artifacts, not just after changing the source dependency file.

Typical attack path

1. Identify an application feature that accepts user-controlled rich text, HTML, SVG, MathML, or embedded markup.
2. Determine or infer that the application uses DOMPurify before version 3.4.0 with custom function-based tag handling.
3. Submit crafted markup that should be blocked by FORBID_TAGS but can survive because of the ADD_TAGS / EXTRA_ELEMENT_HANDLING logic path.
4. Wait for the sanitized content to be rendered in another user’s browser or trigger the victim to view it.
5. Leverage execution in the victim’s browser context to read accessible page data, perform same-origin actions, modify page content, or initiate phishing/account-abuse actions.

How to detect it

There are no universal exploitation indicators because exploitation depends on the application’s DOMPurify configuration, where sanitized content is stored or reflected, and the attacker’s chosen markup. Start by identifying exposure: review dependency manifests and built JavaScript bundles for DOMPurify versions before 3.4.0, then identify code paths using function-based ADD_TAGS, CUSTOM_ELEMENT_HANDLING, or EXTRA_ELEMENT_HANDLING with FORBID_TAGS. To investigate possible prior exploitation, review application logs, WAF logs, CDN logs, API request bodies, and stored user-generated-content records for unusual HTML, SVG, MathML, custom elements, event-handler attributes, script-capable URL schemes, or repeated sanitizer probing. Focus on features that store and later render content to other users, such as comments, messages, rich-text fields, profile pages, admin notes, knowledge-base content, and document preview workflows. Browser telemetry, CSP violation reports, and frontend error monitoring may reveal attempted or successful XSS via blocked inline script, blocked external script loads, unexpected navigation, DOM exceptions, or unusual requests immediately after viewing user-generated content. If suspicious content is found, preserve the original submitted markup, sanitized output, submitter identity, timestamps, affected content identifiers, viewer access logs, and any CSP reports for incident scoping.

What your security team should do

• Inventory all applications and packages that include DOMPurify, prioritizing internet-facing applications and features that render user-generated HTML, SVG, MathML, markdown-to-HTML output, WYSIWYG editor content, comments, messages, profiles, or uploaded documents.
• Upgrade DOMPurify to 3.4.0 or later and redeploy all affected frontend bundles, containers, server-rendering services, and CDN-hosted assets.
• Search code repositories for DOMPurify configurations using FORBID_TAGS together with ADD_TAGS, CUSTOM_ELEMENT_HANDLING, or EXTRA_ELEMENT_HANDLING and require additional review for those usages.
• Add sanitizer regression tests covering forbidden tag removal in custom tag-handling configurations.
• Review historical user-generated content for suspicious markup if vulnerable configurations were present in stored-content workflows.
• Strengthen browser-side mitigations such as Content Security Policy, HttpOnly and SameSite cookies, and restrictions on inline script execution to reduce XSS impact.
• Monitor for newly published exploit examples or changes in EPSS/KEV status, even though current exploit maturity is listed as none and EPSS is low.