Shopware: Stored XSS via SVG file upload — no SVG sanitization
Published 4 Jun 2026 · Updated 10 Sept 2026
Affected packages
- Affected
- >=6.7.0.0 <6.7.10.1
- Fixed in
- 6.7.10.1
composer require shopware/core:^6.7.10.1- Affected
- <6.6.10.18
- Fixed in
- 6.6.10.18
composer require shopware/core:^6.6.10.18- Affected
- >=6.7.0.0 <6.7.10.1
- Fixed in
- 6.7.10.1
composer require shopware/platform:^6.7.10.1- Affected
- <6.6.10.18
- Fixed in
- 6.6.10.18
composer require shopware/platform:^6.6.10.18Details
SVG files are in the allowed_extensions whitelist and can be uploaded by any admin user via the media manager. There is zero SVG content sanitization anywhere in the upload pipeline. A malicious SVG with JavaScript (onload, <script>, <foreignObject>) executes in the context of the Shopware domain when accessed.
The Problem
In src/Core/Framework/Resources/config/packages/shopware.yaml, line 194:
allowed_extensions: ["jpg", "jpeg", "png", "webp", "avif", "gif", "svg", ...]
SVG is whitelisted. The upload path (MediaUploadController → FileSaver → TypeDetector) recognizes SVG as ImageType with VECTOR_GRAPHIC flag, but no code strips JavaScript, event handlers, or external entity references from the SVG XML.
A search of the entire codebase for SVG sanitization returns — no DOMPurify, no svg-sanitize, no strip_tags on SVG content, nothing.
Impact
Stored XSS affecting all users who view the uploaded SVG. In an e-commerce context, this can lead to admin account takeover, customer data theft, or malicious plugin installation.
Suggested Fix
Either:
1. Remove SVG from allowed_extensions if SVG upload is not a core requirement
2. Sanitize SVG content on upload using a library like enshrined/svg-sanitize (strips scripts, event handlers, external references)
3. Serve SVGs with Content-Disposition: attachment to prevent inline rendering
4. Serve SVGs from a separate domain (like Nextcloud's usercontent.apps.nextcloud.com)
Option 2 is the most practical — enshrined/svg-sanitize is already used by WordPress and other PHP projects.
Regards & BG, Keyvan Hardani
Is GHSA-xvhc-gm7j-mhmc in any of your client repos?
Checking one package by hand is fine. Checking it across forty client projects is not. NPMscan reads the lockfiles in every GitHub repo you pick, finds each project with an affected shopware/core, and gives you the command that fixes it.
References
Advisory data from OSV.dev (opens OSV.dev in a new tab), refreshed daily.