What changed
On October 27, 2026, PortSwigger's Gareth Heyes published reproducible browser and sanitizer tests against eight selected SVG sanitization libraries, reporting working bypasses in six. The affected examples were mattkrick/sanitize-svg, Borewit/svg-sanitizer, bgalek/safe-svg, alnorris/SVG-Sanitizer, cloudflare/svg-hush and jams2/py-svg-hush. Techniques included XHTML namespace switches and foreignObject handling, SVG animations changing link targets, XML stylesheet instructions, and Safari treating same-origin GIF payloads as referenced SVG through use. A Firefox Link response-header/XSLT demonstration shows that even an innocuous XML body can become active under certain response conditions. DOMPurify and darylldoyle/svg-sanitizer resisted the payloads in this particular test; that does not make either universally invulnerable. No cross-library patched-version matrix or production-exploitation statistics were published.
Why it matters
A site can sanitize an SVG upload yet still render active content if the browser interprets a different namespace, a same-origin referenced resource, an XSLT stylesheet or another response context than the sanitizer checked. The exposure is especially relevant to CMSs, profile-image uploads, design tools, file-sharing and user-generated page builders that serve SVG from trusted origins. Operators should review where untrusted SVG can be opened directly or embedded, audit library-specific weaknesses, apply restrictive Content Security Policy and isolation, and prefer rasterization or dedicated asset origins for untrusted images. A simple package upgrade cannot be recommended without confirmed fixes for the particular library and path.
What the six failures actually covered
The researcher named eight libraries and described concrete proof-of-concept payloads for six. The selection was not a random ecosystem-wide audit, so six of eight is a result for this tested set, not a vulnerability rate for all SVG tooling. Some payloads require clicking links, opening SVG as a document or loading same-origin referenced files; do not collapse these into one-click universal remote code execution.
Parser disagreement creates unexpected script paths
Changing XML namespaces can make elements behave as HTML; SVG animation can change a seemingly safe link into a script URL. Self-contained XSLT processing instructions were shown to produce executable markup in relevant browsers. The Firefox demonstration used a response Link header with an XSLT data URL while the XML body itself appeared benign. These are context-sensitive browser behaviours, not proof that arbitrary ordinary image tags execute scripts.
Safari cross-file references break simplistic filtering
Safari can import a same-origin file via SVG use even if the referenced file has a GIF extension and contains a crafted SVG payload. A sanitizer that only checks the primary SVG and allows local references can therefore miss the content loaded at rendering time. The researcher demonstrated this against cloudflare/svg-hush, jams2/py-svg-hush and bgalek/safe-svg; production exploitability depends on upload controls, origin policy, content types and browser version.
Defence-in-depth and limits of the evidence
Cloudflare's svg-hush documentation explicitly recommends a restrictive CSP even after filtering, and DOMPurify documents that sanitization safety depends on the insertion context. For high-risk uploads, consider serving from a separate untrusted origin with restrictive headers, disallowing cross-file references, or converting to a non-scriptable raster format. No universal fix version, CVE list or proof of active exploitation accompanied the October 27 research; verify upstream advisories and retest before claiming a system is patched.