DOMPurify <=3.4.10 Hook Pollution Bypass Leading to XSS

Vulnerability Overview A security fix (Persistent Hook Pollution) in DOMPurify 3.4.7 registers an hook to monitor for non-persistent mutations of , ensuring that attribute allowances for a single element do not leak to others. However, this fix is flawed. When an application uses the API, the clone guard within is silently bypassed, resulting in the permanent pollution of the object. Scope Affected Versions: DOMPurify <= 3.4.10 Fixed Version: DOMPurify 3.4.11 Severity: Low CVE ID: None known Weaknesses: CWE-79, CWE-471, CWE-665 Remediation The fix involves cloning and when registering the hook if the flag is true within the function. This prevents hook mutations from persisting. The specific code change is: Proof of Concept (PoC) Code PoC 1 — Leak (Trust Rendering Permanently Allows on Attacker Content) PoC 2 — It Is DOMPurify State Leak, Not "App Allows " (Attribute-Agnostic) PoC 3 — Control: Without , the 3.4.7 Guard Holds Persistence (Observed) The leak persists after — removing hooks does not clean up the polluted allowlist. It is global/cross-element — the polluted allowlist survives on and tags, not just the originally blessed . It persists throughout the instance's lifecycle (surviving after 5 subsequent default calls). restores a clean state (this defines the boundary of impact). Impact Stored XSS. In long-running or same-origin DOMPurify instances, a single trusted render flips the shared allowlist. Subsequently, every non-trusted render injects an event handler attribute that executes script in the browser. Because DOMPurify does not enforce no/noscript blocking, a surviving attribute eventually executes without secondary controls to block it. triggers on broken tags without requiring user interaction (browser confirmed: verified). Per-call does not mitigate this. Defensive calls like are ignored because has already been called: per-call configurations are parsed by , and completely skips . Therefore, the application cannot blunt the leak via per-call denials — the polluted is the sole gating factor. Real-World Attack Scenario A platform mixes admin-driven interactive widgets and user-generated content through a single sanitizer instance. 1. The application installs a persistent baseline policy via . 2. An hook is registered to enable event handlers only for admin-driven elements marked with , intending them to be rendered interactively only — the 3.4.7 fix was designed specifically for this. 3. An admin renders a trusted widget. From that point on, every user-submitted comment/post containing passes through the sanitizer and executes for all viewers. Limitations Requires both prerequisites mentioned above (persistent and a hook writing to ). It is not a default configuration bypass. Impact is bounded by , which restores a clean state. Previous claims that "state survives " were not reproducible and have been withdrawn. Positioning can be adapted to use instead of . However, the 3.4.7 security fix exists specifically to defend against the hook pattern in the per-call path; leaving the path unprotected is an incomplete fix for a known security issue. Verification Integrity: The tested (md5 ) and browser (md5 ) bytes are identical to those downloaded from the npm package. The mechanism is identical in versions 3.4.0, 3.4.9, and 3.4.10. Node (Mechanism): PoCs 1-3 behave as expected: returns after a trusted render, proving the shared attribute gate is poisoned. The leak persists after , is cross-element, persists within the instance lifecycle, and resets after . Real Browser (Impact)**: In Chrome, DOMPurify 3.4.10 outputs the attacker payload to , executing the surviving ( ; the ), without user interaction. A no- A/B control does not trigger — execution is attributed to the leak, not a hammer artifact. Appendix A — Node PoC (Complete, Runnable) Expected Output Appendix B — Browser PoC (Complete, Confirms Execution) Observed

Goal Reached Thanks to every supporter — we hit 100%!

DOMPurify <=3.4.10 Hook Pollution Bypass Leading to XSS

More from this source