CVE-2023-34099

Shopware is an open commerce platform. From 6.7.0.0 to before 6.7.6.1, a regression of CVE-2023-2017 leads to an array and array crafted PHP Closure not checked being against allow list for the map(...) override. This vulnerability is fixed in 6.7.6.1.

The backend/Login/load/ script in Shopware before version 5.1.5 allows remote attackers to execute arbitrary code.

Shopware prior to versions 6.6.10.18 and 6.7.10.1 contains an SSRF vulnerability in the `/api/_action/media/external-link` endpoint. An authenticated admin can send HEAD requests to arbitrary internal IPs because the `linkURL` flow only performs a URL format check (regex for http/https prefix), while the `uploadFromURL` flow properly blocks private addresses.

In Shopware versions 6.7.3.0 through 6.7.10.0, an open redirect vulnerability exists in the SSO endpoint `/api/oauth/sso/auth`. When the expected SSO session state is missing, the application uses the `Referer` header as the redirect target without validation, allowing an attacker to control the destination URL, including dangerous schemes like `javascript:`.

In Shopware prior to versions 6.6.10.18 and 6.7.10.1, the Store API endpoint /store-api/handle-payment does not verify order ownership or guest authentication, allowing a normal customer or guest to trigger payment for another user's order.

In Shopware before versions 6.6.10.18 and 6.7.10.1, SVG files are allowed in the extension whitelist and can be uploaded via the media manager without SVG content sanitization. This allows malicious JavaScript (e.g., onload, <script>, <foreignObject>) to execute in the Shopware domain when the uploaded SVG is viewed.

In Shopware before versions 6.6.10.18 and 6.7.10.1, ACL declarations are missing in order state transition endpoints, allowing low-privileged users to modify order, transaction, and delivery states without proper permissions.

In Shopware prior to versions 6.6.10.18 and 6.7.10.1, the upsertUser() method in UserController writes raw user data in SYSTEM_SCOPE without filtering the admin field. This allows a non-admin API user with user:create or user:update ACL permission to set admin: true on new or existing users.

In Shopware before versions 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. The root cause is that the hash field in UserRecovery entity is not marked as ApiAware(false) or ReadProtection, allowing the password reset hash to be read via the Admin API.

In Shopware prior to versions 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 via the Sync API endpoint POST /api/_action/sync, which lacks proper validation of the admin field.