rhukster dom-sanitizer EUVD-2026-90847

Exploitation requires that a host application uses rhukster/dom-sanitizer ≤1.0.15 to sanitize untrusted HTML AND relies on it to block dangerous URL schemes. The specific gap is that DOMSanitizer::isDangerousUrl() only scheme-validated href and xlink:href, so a javascript: or non-image data: URI placed in any other allow-listed URL-bearing attribute (action, cite, poster, src, srcset, background) bypassed the check - the headline case being a form action, which yields a complete submittable form since form/button/input/type are all allow-listed. Limiting factors: the attacker needs the privilege to submit content that passes through the sanitizer (PR:L), and a victim must interact (UI:P) - typically viewing the stored content and submitting the crafted form for the payload to fire. Applications not using this library, or not depending on its URL-scheme filtering, are unaffected.

The vendor CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:P) scores 5.1 (medium), and the E:P modifier plus the input's POC signal align - a proof-of-concept exists (published in the GHSA-mrpv-6x26-mf6c advisory) but there is no public exploit identified in the sense of active exploitation, and this CVE is not in CISA KEV. No EPSS score is provided. The signals are internally consistent: this is a genuine but modest-impact flaw, not a high-CVSS/low-real-risk mismatch nor a KEV-grade priority. The core caveat is architectural: dom-sanitizer is a security control (an HTML/DOM sanitizer), so a bypass is only exploitable to the extent that a downstream application relies on this library to neutralize untrusted content - the impact is entirely dependent on host-application context, which the CVE does not and cannot enumerate. Attack vector is network and complexity is low, but exploitation requires that attacker-supplied markup actually flows through DOMSanitizer and is later rendered/submitted by a victim (UI:P), bounding real-world severity to the medium range the vendor assigned.

An attacker submits content containing a URL-bearing attribute other than a hyperlink - most notably a complete, submittable <form action="javascript:..."> - to an application that uses dom-sanitizer ≤1.0.15 to clean user input. Because isDangerousUrl() only scheme-checked href/xlink:href, the javascript:/data: payload survives sanitization and executes in a victim's browser when the stored content is viewed and the form is submitted. A proof-of-concept is published in the vendor's GitHub security advisory.