# Six of eight SVG sanitizers failed PortSwigger's tests — browser parsing makes upload safety harder PortSwigger researcher Gareth Heyes demonstrated script-execution bypasses in six selected SVG sanitizers using namespace tricks, animation, XSLT and Safari's image-import behaviour. The result is a warning for sites accepting user SVG, not proof every installation is exploitable. Six of eight SVG sanitizers in a PortSwigger test had bypasses; developers must review SVG upload and rendering contexts, CSP and library versions. - Status: Active - Published: 2026-10-28T21:53:59+13:00 - Updated: 2026-10-28T21:53:59+13:00 - Categories: Web Development, JavaScript, Browsers & Web Standards, Developer Tools - Tags: browser security, JavaScript, security, security testing, SVG - Canonical HTML: https://beyondthe.news/dossiers/portswigger-svg-sanitizer-bypasses-2026-safari-firefox-xml-xslt ## 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. ## Key details - Research published October 27, 2026 by PortSwigger's Gareth Heyes. - Eight selected SVG sanitizer projects tested; six had demonstrated bypasses in the reported scenarios. - The report's resistant libraries were DOMPurify and darylldoyle/svg-sanitizer for the tested payloads only. - Techniques span XML namespaces, SVG animation, XSLT, Firefox Link headers and Safari same-origin GIF-as-SVG references. - Researcher said two real applications were affected but not yet named; no evidence of widespread exploitation provided. - No reliable cross-project patched-version matrix was published with the research. ## Builder takeaways - Inventory every route that accepts, transforms, stores or serves untrusted SVG and determine its rendering context. - Audit sanitizer choice and configuration against the specific PoCs; don't assume a pass on one test proves safety. - Avoid serving arbitrary user SVG as a trusted same-origin top-level document; consider a separate asset origin or rasterization. - Enforce a restrictive Content Security Policy and avoid permissive local-resource references; test Safari and Firefox behaviour. - Track upstream library and browser security updates; don't invent patch versions where none are documented. ## What to watch - Upstream advisories and fixed versions for each affected sanitizer. - Disclosure of the two unnamed affected applications and their remediation. - Browser changes to XSLT and SVG resource import semantics, including XSLT deprecation. - Independent reproduction against current library releases and real application configurations. ## Uncertainties - The selection of eight libraries was researcher-chosen and not a representative prevalence study. - Library and browser versions used in each PoC are not consolidated into a tested patch matrix. - No independent large-scale reproduction or known in-the-wild exploitation data was established. - Not all demonstrated vectors have the same preconditions or severity. ## Sources - [Scalable Vector Grief](https://portswigger.net/research/scalable-vector-grief) — PortSwigger Research · primary_security_research · 2026-10-27T00:00:00+13:00. Original technical research, eight tested projects, six bypassed, proof-of-concept details and explicit caveats. - [svg-hush repository and security model](https://github.com/cloudflare/svg-hush) — Cloudflare · primary_project_documentation. Documents SVG sanitization scope, same-origin reference behaviour and CSP defence-in-depth. - [DOMPurify attack classes and bypass history](https://github.com/cure53/DOMPurify/wiki/Attack-Classes-%26-Bypass-History) — Cure53 · primary_project_documentation · 2026-06-05T00:00:00+12:00. Context-dependent parsing and historical bypass classes; not independent validation of PortSwigger's exact PoCs. - [Scalable Vector Grief independent coverage](https://root2sec.com/exploits/scalable-vector-grief/) — Root2Sec · specialist_secondary · 2026-10-28T00:00:00+13:00. Contemporaneous technical summary; derivative, not independently reproduced.