The Shopware Store API endpoint /store-api/handle-payment contains an object-level authorization flaw that allows a low-privileged external user with a normal customer or guest context to trigger the payment flow for another user’s order by supplying a foreign orderId. The affected functionality is the Store API payment initiation and retry flow. The root cause is that the endpoint forwards the user-controlled orderId into the payment processing logic without verifying that the …
There is a Proof of Concept which is able to enumerate the usernames of administrator users. This was possible by performing a timing attack.
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 /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.
UserController::upsertUser() writes user data in SYSTEM_SCOPE and does not filter the admin field. A non-admin API user with user:create or user:update ACL permission can set admin: true on new or existing users, escalating to full admin access.
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) correctly blocks this, but the Sync API bypasses the controller-level check by writing directly through the DAL EntityWriter. The integration entity definition lacks WriteProtection, and the admin field has no field-level restriction flag. OWASP: A01:2021 — Broken Access …
This is a vertical authorization bypass in the Admin API affecting order state transition features (/api/_action/order/{orderId}/state/{transition} and similar transaction/delivery transition routes). The root cause is that the transition action routes do not declare required server-side ACL privileges, allowing low-privileged users to pass the authorization boundary. As a result, authenticated users without order:update can still change order states, causing real security impact such as operational integrity loss, automation workflow misuse, and …
A low-privilege admin user with user_recovery:read ACL can take over any admin account. The attacker triggers password recovery for the victim (unauthenticated endpoint), reads the recovery hash from the Admin API search endpoint, then uses the hash to reset the victim's password (another unauthenticated endpoint). The recovery hash — intended to be secret and delivered only via email — is fully readable through the standard entity search API. OWASP: A01:2021 …
This report describes 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 …
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.
We identified and fixed 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. By abusing app re‑registration, an attacker could redirect app traffic to an attacker‑controlled domain and potentially obtain API credentials intended for the legitimate shop. We have no evidence that this vulnerability has been exploited.
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.
We fixed with CVE-2023-2017 Twig filters to only be executed with allowed functions. However there was a regression that lead to an array and array crafted PHP Closure not checked being against allow list for the map(…) override