GHSA-xvhc-gm7j-mhmc
MEDIUMShopware: Stored XSS via SVG file upload — no SVG sanitization
Blast Radius
shopware/core🐘shopware/core🐘shopware/platform🐘shopware/platformReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects Packagist packages — download data is not available via public APIs for these ecosystems.
Description
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:
- Remove SVG from
allowed_extensionsif SVG upload is not a core requirement - Sanitize SVG content on upload using a library like
enshrined/svg-sanitize(strips scripts, event handlers, external references) - Serve SVGs with
Content-Disposition: attachmentto prevent inline rendering - 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
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐘Packagist | shopware/core | ≥ 6.7.0.0&&< 6.7.10.1 | 6.7.10.1 |
| 🐘Packagist | shopware/core | all versions | 6.6.10.18 |
| 🐘Packagist | shopware/platform | ≥ 6.7.0.0&&< 6.7.10.1 | 6.7.10.1 |
| 🐘Packagist | shopware/platform | all versions | 6.6.10.18 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for shopware/core. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.
Fix
Update shopware/core to 6.7.10.1 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-xvhc-gm7j-mhmc is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 pinpoints whether GHSA-xvhc-gm7j-mhmc is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.
Tailored to GHSA-xvhc-gm7j-mhmc. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is GHSA-xvhc-gm7j-mhmc in your dependencies?
O3 detects GHSA-xvhc-gm7j-mhmc across Packagist dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.