Shopware Shopware vulnerabilities

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.

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.

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.

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.

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.

Shopware is an open commerce platform. Prior to 6.6.10.18 and 6.7.10.1, UserController::upsertUser() in src/Core/Framework/Api/Controller/UserController.php writes raw user data in SYSTEM_SCOPE without filtering the admin field, so a non-admin API user with user:create or user:update ACL permission can set admin: true on new or existing users; IntegrationController::upsertIntegration() contains an isAdmin() check for the same field, but UserController was missing this check. This issue is fixed in versions 6.6.10.18 and 6.7.10.1.

Shopware is an open commerce platform. Prior to 6.6.10.18 and 6.7.10.1, a low-privilege admin user with user_recovery:read ACL can take over any admin account by triggering POST /api/_action/user/user-recovery, reading the password recovery hash through POST /api/search/user-recovery, and using PATCH /api/_action/user/user-recovery/password; the root cause is that src/Core/System/User/Recovery/UserRecoveryDefinition.php exposes the hash field through the Admin API without ApiAware(false) or ReadProtection. This issue is fixed in versions 6.6.10.18 and 6.7.10.1.

Shopware is an open commerce platform. Prior to 6.6.10.18 and 6.7.10.1, a non-admin API user with integration:create ACL privilege can escalate to full administrator by creating an integration with admin: true through the Sync API POST /api/_action/sync; the regular integration endpoint POST /api/integration blocks this, but SyncController::sync() routes writes through SyncService to EntityWriter::upsert(), and src/Core/Framework/Integration/IntegrationDefinition.php lacks WriteProtection on the admin field. This issue is fixed in versions 6.6.10.18 and 6.7.10.1.

Shopware is an open commerce platform. Prior to 6.7.8.1 and 6.6.10.15, the Store API login endpoint (POST /store-api/account/login) returns different error codes depending on whether the submitted email address belongs to a registered customer (CHECKOUT__CUSTOMER_AUTH_BAD_CREDENTIALS) or is unknown (CHECKOUT__CUSTOMER_NOT_FOUND). The "not found" response also echoes the probed email address. This allows an unauthenticated attacker to enumerate valid customer accounts. The storefront login controller correctly unifies both error paths, but the Store API does not — indicating an inconsistent defense. This vulnerability is fixed in 6.7.8.1 and 6.6.10.15.

Shopware is an open commerce platform. Versions 6.4.6.0 through 6.6.10.9 and 6.7.0.0 through 6.7.5.0 have a Reflected XSS vulnerability in AuthController.php. A request parameter from the login page URL is directly rendered within the Twig template of the Storefront login page without further processing or input validation. This allows direct code injection into the template via the URL parameter, waitTime, which lacks proper input validation. This issue is fixed in versions 6.6.10.10 and 6.7.5.1.