DOMPurify CVE-2026-75838

Three concurrent conditions must be met: (1) the application must explicitly pass IN_PLACE: true in the DOMPurify configuration - this is a non-default mode that must be deliberately opted into by the developer; (2) the application must register a hook via DOMPurify.addHook() on 'uponSanitizeElement' or 'beforeSanitizeElements' that calls node.remove() on a matched element during sanitization; and (3) the attacker must be able to supply HTML content that the application passes to DOMPurify.sanitize(). The attacker does not need any privileges against the DOMPurify library itself; their access to the HTML injection point is determined solely by the host application's own authentication and authorization controls. Exploitation is further constrained to browsers that queue resource events (such as img onload with a data-URI src) during DOM construction before sanitization completes - behavior confirmed in Chromium. Applications using DOMPurify without IN_PLACE mode, or with IN_PLACE mode but no element-removal hooks, are not affected by this specific code path.

The vendor-assigned CVSS 4.0 score of 5.1 (AV:N/AC:L/AT:N/PR:L/UI:P/VC:N/VI:N/VA:N/SC:L/SI:L/SA:N) accurately reflects moderate real-world severity; the subsequent-system impact metrics SC:L and SI:L capture the typical XSS consequence of arbitrary JavaScript execution in the victim's browser session. No EPSS data was provided in the input, so exploitation probability is inferred from the public PoC: a working exploit targeting DOMPurify 3.4.12 is embedded in the GHSA advisory itself, which substantially increases near-term exploitation likelihood compared to the moderate CVSS score alone - even a mid-sized municipal IT team in walbrzych running a web application with custom DOMPurify hooks should treat this as urgent given how low the attacker's bar is once the preconditions exist. The critical limiting factor is the double precondition: the application must both enable IN_PLACE mode explicitly and register an element-removal hook, narrowing the exploitable population considerably compared to a default-configuration flaw. This vulnerability is not listed in the CISA KEV catalog at time of analysis, so active exploitation is not confirmed; the PR:L metric in the provided vector suggests the vendor models the attacker as needing some application-level access to supply HTML, though the actual privilege requirement depends entirely on the host application's access controls. No conflicting signals exist across the GHSA advisory, ENISA EUVD entry, and VulnCheck data; all are internally consistent.

An attacker targeting a web application that accepts user-supplied HTML - such as a rich-text comment field or content import feature - crafts a payload containing an img element with a data-URI src and an onload event handler, nested inside a footer element that a registered uponSanitizeElement hook removes via node.remove(). The application calls DOMPurify.sanitize(root) with IN_PLACE: true; the hook fires for the footer element, detaches it (and the img descendant), and the function returns early - bypassing _neutralizeSubtree(). When the event loop advances after sanitize() returns, the browser fires the pre-queued onload event on the still-disconnected img, executing the attacker's JavaScript in the victim's page context. A working proof-of-concept demonstrating this exact flow against DOMPurify 3.4.12 in Chromium is publicly available in the GHSA advisory.