Уязвимости shopware/platform

Shopware SSO referer trust leading to an arbitrary redirect target

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

• Обновитесь до 6.7.10.1

Shopware: SSRF in Media External-Link Endpoint Bypasses IP Validation

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.

• Обновитесь до 6.7.10.1

Shopware: Admin Account Takeover via User Recovery Hash Exposure

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.

• Обновитесь до 6.6.10.18
• Обновитесь до 6.7.10.1

Shopware: Admin API ACL Bypass in Order State Transition Endpoints

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.

• Обновитесь до 6.6.10.18
• Обновитесь до 6.7.10.1

Shopware: Privilege escalation: non-admin user with user:create ACL can create admin accounts

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.

• Обновитесь до 6.6.10.18
• Обновитесь до 6.7.10.1

Shopware: Unauthorized Payment Trigger for Foreign Orders via /store-api/handle-payment

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.

• Обновитесь до 6.6.10.18
• Обновитесь до 6.7.10.1

Shopware: Stored XSS via SVG file upload — no SVG sanitization

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.

• Обновитесь до 6.6.10.18
• Обновитесь до 6.7.10.1

Shopware: Privilege Escalation via Sync API Integration Admin Flag Bypass

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.

• Обновитесь до 6.6.10.18
• Обновитесь до 6.7.10.1

Shopware: Timing-attack on admin panel allowing enumeration of administrator usernames

Shopware is an open commerce platform. Prior to versions 6.6.10.18 and 6.7.10.1, an attacker is able to enumerate the usernames of administrator users by performing a timing attack. Versions 6.6.10.18 and 6.7.10.1 fix the issue.

• Обновитесь до 6.6.10.18
• Обновитесь до 6.7.10.1

Shopware has a potential take over of app credentials

Shopware is an open commerce platform. Prior to 6.6.10.15 and 6.7.8.1, a vulnerability in the Shopware app registration flow that could, under specific conditions, allow attackers to take over the communication channel between a shop and an app. The legacy app registration flow used HMAC‑based authentication without sufficiently binding a shop installation to its original domain. During re‑registration, the shop-url could be updated without proving control over the previously registered shop or domain. This made targeted hijacking of app communication feasible if an attacker possessed the relevant app‑side secret. By abusing app re‑registrati

• Обновитесь до 6.6.10.15
• Обновитесь до 6.7.8.1

Shopware has user enumeration via distinct error codes on Store API login endpoint

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.6.10.14
• Обновитесь до 6.7.8.1

Shopware unauthenticated data extraction possible through store-api.order endpoint

Shopware is an open commerce platform. Prior to 6.7.8.1 and 6.6.10.15, an insufficient check on the filter types for unauthenticated customers allows access to orders of other customers. This is part of the deepLinkCode support on the store-api.order endpoint. This vulnerability is fixed in 6.7.8.1 and 6.6.10.15.

• Обновитесь до 6.6.10.15
• Обновитесь до 6.7.8.1

Shopware Customer Orders can be canceled, even if refunds are disabled

Refunds in general can be enabled through the administration setting `core.cart.enableOrderRefunds` (in the cart panel).Which visually shows and hides the button. However, using a custom crafted request, a customer can still cancel his own orders.As this is not checked inside the route (and also not in the controller): https://github.com/shopware/shopware/blob/trunk/src/Storefront/Controller/AccountOrderController.php#L98 https://github.com/shopware/shopware/blob/trunk/src/Core/Checkout/Order/SalesChannel/CancelOrderRoute.php To mitigate this, a check should be added to the `CancelOrderRoute` which verifies that the feature is enabled.

• Обновитесь до 6.6.10.7
• Обновитесь до 6.7.3.1

Shopware exposes sensitive user information via CSV export mapping

### Impact Malicious actors can exploit this finding to export sensitive customer information from a Shopware application, including password hashes and password reset tokens. In SaaS deployments, this primarily affects customer accounts. In on-premise deployments, however, it also includes the hashes and recovery tokens of administrator-level accounts, which increases the potential impact. This risk is noteworthy because users may reuse the same or similar passwords across different services. In such cases, exposed hashes could allow attackers to recover credentials that might also be valid outside of Shopware. #### Description Sensitive i

• Обновитесь до 6.6.10.7
• Обновитесь до 6.7.3.1

Shopware vulnerable to Server-Side Request Forgery (SSRF) – order invoice

### Impact This vulnerability allows malicious actors to force the application server to send HTTP requests to both external and internal servers. In certain cases, this may lead to access to internal resources such as databases, file systems, or other services that are not supposed to be directly accessible from the internet. The overall impact of this vulnerability is considered limited, as the functionality is highly restricted and only processes IMG tags. #### Description Server-Side Request Forgery (SSRF) is a vulnerability that enables a malicious actor to manipulate an application server into performing HTTP requests to arbitrary dom

• Обновитесь до 6.6.10.7
• Обновитесь до 6.7.3.1

Shopware vulnerable to path traversal via Plugin upload

### Impact Malicious actors can exploit this vulnerability to write files within arbitrary directories on the filesystem of the Shopware web container. This could allow them to gain persistent shell access by uploading a PHP-shell file to an accessible folder. It is important to note that this vulnerability is only present on on-premises installation of Shopware and not present on the SaaS installation due to additional security checks being implemented on the uploaded plugin files. #### Description A path traversal vulnerability allows malicious actors to access files and folders that are outside the folder structure accessible to the affe

• Обновитесь до 6.6.10.7
• Обновитесь до 6.7.3.1

Shopware vulnerable to MediaVisibilityRestrictionSubscriber bypass when reading media entities by aggregating fields individually

In Shopware core and platform versions before 6.6.10.7 and 6.7.3.1, media visibility restrictions applied by MediaVisibilityRestrictionSubscriber are not enforced for aggregation API requests. Authorization filters are only injected during standard entity reads; aggregation queries can be constructed to bypass these checks and enumerate private media records such as invoices or other restricted documents. A low‑privilege backend user (e.g., product editor) can chain normal business flows (creating or viewing orders) with aggregation queries to disclose sensitive customer data including addresses and payment-related information contained withi

• Обновитесь до 6.6.10.7
• Обновитесь до 6.7.3.1

Race Condition in Shopware Voucher Submission

A race condition vulnerability has been identified in Shopware's voucher system of Shopware v6.6.10.4 that allows attackers to bypass intended voucher restrictions and exceed usage limitations.

CVE-2025-27892

Shopware prior to version 6.5.8.13 is affected by a SQL injection vulnerability in the /api/search/order endpoint. NOTE: this issue exists because of a CVE-2024-22406 and CVE-2024-42357 regression.

• Обновитесь до 6.5.8.18
• Обновитесь до 6.6.10.3
• Обновитесь до 6.7.0.0-rc2

Shopware's default newsletter opt-in settings allow for mass sign-up abuse

Shopware is an open source e-commerce software platform. Prior to 6.6.10.3 or 6.5.8.17, the default settings for double-opt-in allow for mass unsolicited newsletter sign-ups without confirmation. Default settings are Newsletter: Double Opt-in set to active, Newsletter: Double opt-in for registered customers set to disabled, and Log-in & sign-up: Double opt-in on sign-up set to disabled. With these settings, anyone can register an account on the shop using any e-mail-address and then check the check-box in the account page to sign up for the newsletter. The recipient will receive two mails confirming registering and signing up for the newslett

• Обновитесь до 6.5.8.17
• Обновитесь до 6.6.10.3
• Обновитесь до 6.7.0.0-rc2