Platform

Shopware is an open commerce platform. Prior to 6.6.10.18 and 6.7.10.1, the Store API endpoint /store-api/handle-payment in src/Core/Checkout/Payment/SalesChannel/HandlePaymentMethodRoute.php accepts a user-controlled orderId and forwards it to src/Core/Checkout/Payment/PaymentProcessor.php without verifying order ownership or guest-order authentication, allowing a normal customer or guest context to trigger the payment flow for another user's order while /store-api/order enforces the expected ownership model. This issue is fixed in versions 6.6.10.18 and 6.7.10.1.

Published: 2026-07-17T17:54:21.990Z
Updated: 2026-07-20T19:27:17.356Z

Shopware is an open commerce platform. Prior to 6.6.10.18 and 6.7.10.1, SVG files are in the allowed_extensions whitelist in src/Core/Framework/Resources/config/packages/shopware.yaml and can be uploaded via the media manager without SVG content sanitization in the upload pipeline from MediaUploadController to FileSaver to TypeDetector, allowing malicious SVG JavaScript such as onload, <script>, and <foreignObject> to execute in the Shopware domain when the uploaded SVG is viewed. This issue is fixed in versions 6.6.10.18 and 6.7.10.1.

Published: 2026-07-17T17:53:01.695Z
Updated: 2026-07-17T18:11:57.809Z

Shopware is an open commerce platform. Prior to 6.6.10.18 and 6.7.10.1, the order state transition features /api/_action/order/{orderId}/state/{transition} and similar transaction and delivery transition routes in src/Core/Checkout/Order/Api/OrderActionController.php do not declare PlatformRequest::ATTRIBUTE_ACL or perform an explicit privilege check, so AclAnnotationValidator exits when route ACL metadata is absent and low-privileged users without order:update, order_transaction:update, or order_delivery:update can trigger StateMachineRegistry::transition() writes in SYSTEM_SCOPE. This issue is fixed in versions 6.6.10.18 and 6.7.10.1.

Published: 2026-07-17T17:56:43.236Z
Updated: 2026-07-21T01:48:04.992Z

Shopware is an open commerce platform. Prior to 6.6.10.18 and 6.7.10.1, the `/api/_action/media/external-link` endpoint allows authenticated admin users to make server-side HTTP HEAD requests to arbitrary internal IP addresses. While the parallel `uploadFromURL` flow validates target IPs against private/reserved ranges via `FileUrlValidator`, the `linkURL` flow only performs a URL format check (regex for `http://` or `https://` prefix), allowing SSRF to internal network services and cloud metadata endpoints. This issue is fixed in versions 6.6.10.18 and 6.7.10.1.

Published: 2026-07-23T19:14:32.579Z
Updated: 2026-07-23T19:27:54.530Z

Shopware is an open commerce platform. Versions 6.7.3.0 through 6.7.10.0 have an open redirect in Shopware's public SSO entry point at `GET /api/oauth/sso/auth`. When the endpoint is reached without the expected SSO session state, the application falls back to the request's `Referer` header and uses that value as the redirect destination. In the validated behavior, the server does not restrict that fallback target to same-origin URLs, does not require a relative path, and does not reject dangerous schemes such as `javascript:`. As a result, an unauthenticated request can turn this endpoint into a reusable redirect primitive whose destination is fully controlled by attacker-supplied request metadata. The security problem is not limited to a harmless navigation mismatch. The endpoint sits under `/api/oauth/`, which gives the redirect a trustworthy application-controlled origin and makes it suitable for phishing chains, branded redirect abuse, and cases where client software automatically follows redirects issued by a trusted host. The attached evidence also shows that the response is not only an HTTP `302` with a user-controlled `Location` header. The HTML body contains a matching meta refresh tag and redirect link built from the same attacker-controlled value. In the validated proof, the endpoint redirects to `https://attacker.example/poc` when that URL is supplied through `Referer`, and it also reflects `javascript:alert(1)` into `Location` and the HTML redirect body without any scheme filtering. This report therefore stays conservative and claims an open redirect with arbitrary redirect targets, while noting that the lack of scheme restrictions makes the behavior materially worse than a same-scheme external redirect. Version 6.7.10.1 fixes the issue.

Published: 2026-07-23T19:16:38.956Z
Updated: 2026-07-24T13:31:43.099Z