svg-sanitizer EUVD-2026-95137

Exploitation requires that: (1) the target application uses svg-sanitizer prior to 1.0.0 and embeds its output INLINE as HTML (not as a referenced <img>/external resource, where HTML5 named-character-reference resolution would not apply to the href); (2) the attacker can supply SVG input to the sanitizer (typically an authenticated content-submission path, consistent with PR:L); and (3) a victim actively activates the resulting link (UI:R). The attacker must craft an SVG using a DTD-defined entity (e.g. a Tab-style named reference) inside an href so that it passes isHrefSafeValue() after entity expansion yet survives serialization as the original entity reference. Limiting factors: no remote-unauthenticated path, mandatory victim interaction, and dependence on the embedding application rendering the SVG inline - applications that render SVG in isolated contexts or sanitize downstream are not exposed.

This is a moderate-severity stored/DOM XSS sanitizer-bypass (CWE-79) with a provided CVSS 3.1 vector of AV:N/AC:L/PR:L/UI:R/S:C/C:L/I:L/A:N scoring 5.4 (Medium). The network attack vector and low complexity are real, but two factors materially constrain real-world risk: PR:L means the attacker must already be able to submit SVG content to the target application (an authenticated contributor/uploader in most deployments), and UI:R means a victim must actively click/activate the crafted link before script executes. The scope change (S:C) correctly reflects that execution lands in the embedding page's origin rather than the sanitizer itself. No EPSS score, KEV listing, or SSVC decision data was provided, and no public exploit was referenced - so there is no public exploit identified at time of analysis. The signals are internally consistent (no CVSS-versus-description conflict): the description's 'a user who activates the link' matches UI:R, and 'application embeds the sanitized SVG inline' matches the stored/second-order nature. Bottom line: a credible defense-in-depth bug worth patching promptly in affected deployments, but not an emergency - it depends on attacker content-submission ability, victim interaction, and the embedding application rendering the SVG inline as HTML.

An attacker with the ability to upload or submit SVG content (e.g. an authenticated user of a CMS, forum, or avatar/upload feature) crafts an SVG whose href uses a DTD-defined entity such as a tab reference that svg-sanitizer validates as safe before entity expansion, while saveXML() re-serializes the original entity reference. When the host application embeds the sanitized SVG inline, HTML5 named-character-reference resolution converts the surviving reference to whitespace and unmasks a javascript: URL. A victim who then clicks the link executes attacker-controlled script in the embedding page's origin. No public exploit code was referenced in the provided data.