svg-sanitizer EUVD-2026-115868

Exploitation requires an application that uses svg-sanitize version 0.5.0 through 1.0.0 to sanitize attacker-supplied SVG content, and that subsequently serves or renders that SVG to a victim. The specific trigger is a CSS escape sequence inside url() within an SVG presentation attribute (e.g. fill="url(\2f\2f evil.example/x)"), where escaped slashes evade the sanitizer's remote-URL removal. Limiting factors: the attack is not self-contained - a victim must open the sanitized SVG in a browser that resolves CSS escape sequences to remote URLs (demonstrated with Chrome), so passive user interaction is required (UI:P); impact is confined to outbound external requests and consequent data exfiltration, the extent of which depends on how the application uses the SVG; applications not using this library for SVG sanitization, or already on 1.1.0+, are unaffected.

This is a medium-severity (CVSS 4.0 base 5.3) information-disclosure issue, and the combined signals argue for scheduled rather than emergency remediation - consistent with the vuln.today 'this_month' decision label. The provided CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:P/VC:L/VI:N/VA:N) shows a network-reachable, low-complexity flaw needing no attacker privileges but requiring passive victim interaction (UI:P) - the victim must render the sanitized SVG in a browser - with only low confidentiality impact and no integrity or availability impact. No EPSS score and no CISA KEV status were supplied, so there is no quantitative exploitation-probability or active-exploitation signal to weigh; absence of these is not evidence of safety but means widespread automated exploitation cannot be inferred. A public PoC reference exists in the GHSA advisory (a working SVG and reproduction steps against Chrome) but the input does not mark it as confirmed working exploit code, so treat it as a public PoC reference, not a confirmed weaponized exploit. The main risk driver is prevalence: svg-sanitize is a widely used PHP sanitization library, so many applications could inherit this bypass, but the actual impact per deployment is bounded (limited data exfiltration via outbound requests, dependent on how the SVG is used). Net: a real but moderate-priority issue, not a high-CVSS-but-illusory one, yet also not an emergency.

An attacker submits an SVG whose presentation attribute uses a CSS-escaped remote URL, e.g. fill="url(\2f\2f evil.example/x)", to an application that relies on svg-sanitize (0.5.0-1.0.0) to clean untrusted SVG uploads; the escaped slashes evade the remote-URL stripping and the file is stored and served as 'safe.' When a victim later opens that SVG in a browser such as Chrome, the browser resolves the escape sequence to //evil.example and issues an external request, enabling callback/tracking and data exfiltration depending on context. A public PoC with the exact bypass payload is included in the vendor GHSA advisory.