svg-sanitize CVE-2026-117539

Exploitation requires the attacker to upload an SVG file to the application (PR:L - a low-privileged authenticated uploader in typical deployments) and, for the CSS-injection and host-page data-exfiltration vectors, the SVG must be rendered INLINE in the DOM - the advisory explicitly states these do not apply when the SVG is loaded via <img src="...svg">. A victim must then view the page that renders the SVG (UI:P). The <image href> tracking-pixel and unquoted url() vectors specifically bypass the removeRemoteReferences(true) option, so they work even when that defense is enabled. Limiting factors: no code execution results (data:text/html is blocked by isHrefSafeValue(), so the <a download> polyglot path needs additional crafting plus the victim opening the saved file); impact is confined to confidentiality/tracking; and the highest-value attribute-exfiltration selectors only work where the SVG is inlined into a sensitive page. Affected versions are svg-sanitize < 1.0.0 (vulnerable through 0.22.0); updating to 1.0.0 is the vendor fix.

This is a genuine but moderate-priority issue, not a top-tier emergency. The CVSS 4.0 base score is 5.1 (Medium) with vector AV:N/AC:L/AT:N/PR:L/UI:P: network-reachable and low-complexity, but it requires low-privilege access (PR:L - i.e., the ability to upload an SVG) and passive user interaction (UI:P - a victim must view the rendered page). Impact is limited to confidentiality (VC:L) with no integrity or availability effect, consistent with the described outcomes: CSS-based data exfiltration, user tracking, and visitor IP disclosure rather than code execution. It is NOT in CISA KEV (no KEV signal in the input), so there is no confirmed active exploitation; the GHSA advisory does contain detailed proof-of-concept SVG payloads, so a public PoC reference exists, though it is not verified as working end-to-end exploit code in a specific product. No EPSS score was provided, so exploitation probability cannot be quantified from this data. The vuln.today decision label is 'this_month' (not act_now/emergency), aligning with the medium severity and absence of active exploitation. The main driver of real-world relevance is reach, not severity: svg-sanitize is extremely widely deployed (45.2M Packagist downloads, 90+ dependents, 1M+ WordPress Safe SVG installs, plus TYPO3 and Drupal), so even a medium-severity logic flaw has a large aggregate footprint. Note a vector discrepancy to verify: the GHSA advisory proposes CVSS 3.1 4.3 with UI:N, whereas the input CVSS 4.0 vector uses UI:P (interaction required); the CSS-injection vectors realistically need a victim to view an inline-rendered SVG, so UI:P is the more defensible choice.

An attacker with a normal upload-capable account on a site using svg-sanitize uploads an SVG containing a <style> block with @import/url() or an <image href> pointing at attacker infrastructure. When a victim or admin views a page that renders the SVG inline, the browser fetches the external resources, leaking the visitor's IP, enabling tracking, and - via CSS attribute selectors - exfiltrating host-page data character-by-character. Detailed PoC payloads for all vectors are published in the GHSA advisory, though they are not verified as a packaged working exploit.