DOMSanitizer EUVD-2026-88477

Requires that the target application uses rhukster/dom-sanitizer prior to 1.0.15 to sanitize attacker-influenced HTML/SVG/MathML and then renders or serves that output. The attacker supplies a data: URL (e.g., data:text/html;base64,… or data:application/xhtml+xml / data:image/svg+xml with onload) in an href or xlink:href attribute; the flawed /^data:.*onload/i check only inspects for the literal substring 'onload', so any Base64-encoded payload passes. Exploitation is LIMITED by required victim interaction (UI:R - the victim must follow/interact with the surviving link) and by modern browser policies that block top-level navigation to data:text/html URLs, which can neutralize the most common payload form. No authentication is required to submit the content (PR:N).

This is a genuine but modest-severity sanitizer-bypass flaw, not a high-priority emergency. The CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:N/A:N = 4.7 Medium) is internally consistent with the mechanism: network-reachable content, low complexity, no privileges, but required victim interaction (clicking/following the surviving data: link) and only low confidentiality impact with a scope change into the browser context. No EPSS score, no CISA KEV listing, and no public exploit code were provided - so exploitation status is 'no public exploit identified at time of analysis.' The real-world risk is dampened by two independent factors: (1) it is exploitable only when a downstream application actually uses this specific library to sanitize attacker-controlled HTML/SVG and then renders it, and (2) modern browsers block top-level navigation to data:text/html URLs, meaning the classic data:text/html;base64 payload often fails to execute as active markup in current browsers, making the C:L rating arguably optimistic. The commit evidence and dedicated regression tests firmly CONFIRM the mechanism and the fix. Note the tag 'Information Disclosure' does not match the underlying weakness, which is a sanitizer bypass enabling active markup (XSS-class), even though the vendor mapped impact to C:L rather than I:H.

An attacker submits user-generated content (e.g., an SVG or HTML fragment) to an application that relies on rhukster/dom-sanitizer <1.0.15 to sanitize it. The attacker embeds a href/xlink:href value like data:text/html;base64,<base64 of a script/onload payload>, which survives the flawed /^data:.*onload/i substring check because Base64 hides the dangerous markers; when a victim follows the link, the decoded active markup can run. No public PoC is provided, and success depends on victim interaction (UI:R) and browser handling of data: URLs.