DOMPurify EUVD-2026-48286

Exploitation requires that the target application satisfies both of the following conditions simultaneously: (1) it calls DOMPurify.setConfig() at least once to establish a persistent sanitization policy (this sets the internal SET_CONFIG=true flag, which causes all subsequent sanitize() calls to skip _parseConfig()); and (2) it registers an uponSanitizeAttribute hook via DOMPurify.addHook('uponSanitizeAttribute', ...) that writes data.allowedAttributes[name]=true to conditionally allow a dangerous attribute such as onerror, onclick, onmouseover, onload, srcdoc, or formaction for specific trusted elements. Additionally, an attacker must be able to submit content that is processed by the same DOMPurify instance after a trusted render has already triggered the hook's allowlist mutation. Applications using DOMPurify without setConfig() retain the _parseConfig() clone-guard from 3.4.7 and are NOT affected. Applications using setConfig() but with no uponSanitizeAttribute hook, or with hooks that do not write to data.allowedAttributes, are also NOT affected. The CVSS PR:L confirms that some level of authenticated or application-level access to submit content is required.

The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:P, score 5.1) accurately characterizes the real-world conditions: exploitation is not zero-effort but the complexity is low once the preconditions are met. PR:L indicates an attacker must be able to submit content that is processed through the hook-enabled sanitizer path (e.g., a registered user in a content platform). UI:P captures that stored XSS requires a victim to load the page containing the poisoned content. The subsequent-system impact (SC:L/SI:L) reflects limited but meaningful cross-origin script execution capability - sufficient for session hijacking, credential phishing, or defacement. The vulnerability is most dangerous in multi-tenant applications where user-submitted content and privileged content share the same DOMPurify instance. No KEV listing and no public exploit code have been identified, which tempers urgency, but the bypass mechanism is mechanically straightforward for anyone familiar with DOMPurify internals. The exploit pattern - trigger hook pollution via trusted content, then submit malicious content - is a known stored XSS archetype with no mitigating complexity once the configuration precondition is met. The fact that this is an incomplete fix of a known prior patch (3.4.7) means the attack surface is already documented, slightly elevating exploitation likelihood relative to a novel finding.

An attacker with a low-privilege account on a content platform (e.g., blog commenter, document editor) first submits a legitimate post containing a trusted element (such as one bearing a data-trusted marker) that triggers the application's uponSanitizeAttribute hook to write data.allowedAttributes['onerror']=true, permanently polluting the shared ALLOWED_ATTR. The attacker then submits a second post containing an img tag with an onerror attribute and arbitrary JavaScript payload; because the allowlist is now polluted, DOMPurify passes the attribute through and the content is stored in the database. When any subsequent victim loads a page rendering either post, the onerror handler executes in their browser, enabling the attacker to steal session cookies or perform actions on their behalf. No public exploit code has been identified, but the bypass is reproducible from the published advisory description alone.