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: ```yaml 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
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: ```yaml 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
Update shopware/core to 6.7.10.1; shopware/core to 6.6.10.18; shopware/platform to 6.7.10.1; shopware/platform to 6.6.10.18 if you use the affected versions. Test the change in a non-production environment first.
Local check
hol-guard supply-chain scanShopware: Stored XSS via SVG file upload — no SVG sanitization affects shopware/core (composer), shopware/core (composer), shopware/platform (composer), shopware/platform (composer). Severity is medium. 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: ```yaml 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
AI coding agents often install or upgrade packages automatically in composer. A medium vulnerability in a dependency can be pulled into a project through a normal install or update without a human reviewing the change, expanding the blast radius from a single package to every agent workspace that depends on it.
| Package | Affected range | Fixed version |
|---|---|---|
| shopware/corecomposer | >=6.7.0.0,<6.7.10.1 | 6.7.10.1 |
| shopware/corecomposer | <6.6.10.18 | 6.6.10.18 |
| shopware/platformcomposer | >=6.7.0.0,<6.7.10.1 | 6.7.10.1 |
| shopware/platformcomposer | <6.6.10.18 | 6.6.10.18 |
Fixed versions are reported by the source feed; confirm compatibility before updating.
Reported by GitHub Security Advisories (ghsa).
HOL Guard can help your team review package activity against supported protection paths.
Explore HOL GuardUpdate shopware/core to 6.7.10.1; shopware/core to 6.6.10.18; shopware/platform to 6.7.10.1; shopware/platform to 6.6.10.18 if you use the affected versions. Test the change in a non-production environment first.
Local check
hol-guard supply-chain scanShopware: Stored XSS via SVG file upload — no SVG sanitization affects shopware/core (composer), shopware/core (composer), shopware/platform (composer), shopware/platform (composer). Severity is medium. 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: ```yaml 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
AI coding agents often install or upgrade packages automatically in composer. A medium vulnerability in a dependency can be pulled into a project through a normal install or update without a human reviewing the change, expanding the blast radius from a single package to every agent workspace that depends on it.
| Package | Affected range | Fixed version |
|---|---|---|
| shopware/corecomposer | >=6.7.0.0,<6.7.10.1 | 6.7.10.1 |
| shopware/corecomposer | <6.6.10.18 | 6.6.10.18 |
| shopware/platformcomposer | >=6.7.0.0,<6.7.10.1 | 6.7.10.1 |
| shopware/platformcomposer | <6.6.10.18 | 6.6.10.18 |
Fixed versions are reported by the source feed; confirm compatibility before updating.
Reported by GitHub Security Advisories (ghsa).
HOL Guard can help your team review package activity against supported protection paths.
Explore HOL Guard