DOMPurify EUVD-2026-48272

Exploitation requires the target application to configure DOMPurify with ADD_TAGS in its function/callback form (specifically via EXTRA_ELEMENT_HANDLING.tagCheck), AND to specify overlapping entries in FORBID_TAGS for tags that the callback would approve. This is a non-default, advanced usage pattern; applications using ADD_TAGS as a plain array (the common case) are entirely unaffected. CVSS UI:A (active user interaction) confirms that user-submitted input must be processed and the resulting sanitized HTML must be rendered in a browser context. Exploitation is limited to: (1) DOMPurify versions <= 3.3.3; (2) the function form of ADD_TAGS, not the array form; (3) applications that also set FORBID_TAGS on overlapping tags; and (4) a browser-rendering context where the retained forbidden tag is meaningful. Authentication requirements are not confirmed from available data - the attacker's ability to submit input depends entirely on the application's own access controls.

The provided CVSS 4.0 score of 5.1 with SC:L/SI:L captures the real-world impact reasonably well: this is a subsequent-system (browser/renderer) integrity and confidentiality issue, not a direct server-side compromise. UI:A correctly reflects that a user or process must submit crafted input and render the output. The most critical limiting factor not fully reflected in that score is attack complexity: exploitation requires a very specific, non-default configuration where ADD_TAGS is used in its function callback form (not the common array form) AND the same tags appear in FORBID_TAGS - the advisory itself labels this 'Config-dependent.' No EPSS score was provided; no KEV listing exists. No public proof-of-concept has been identified in the provided intelligence. Real-world risk is therefore low-to-medium despite the library's broad deployment: the majority of DOMPurify consumers use ADD_TAGS as a plain array, which is entirely unaffected. Applications combining the function form with explicit FORBID_TAGS for the same tags - a defensive pattern suggesting heightened security intent - paradoxically bear the highest risk.

A developer configures DOMPurify with ADD_TAGS as a tagCheck callback that approves custom elements and also sets FORBID_TAGS to block specific tags (e.g., 'script' or a custom dangerous element). An attacker submits crafted HTML containing one of those forbidden-but-ADD_TAGS-approved tags; DOMPurify's short-circuit logic retains the tag in sanitized output. When the application renders that output in a browser, the forbidden tag executes - enabling XSS, data exfiltration, or UI redress depending on the tag type. No public PoC is available, but the advisory provides enough detail for an experienced researcher to reproduce the issue.