CVE-2026-48012
MediumCVSS 4.3Exploitation Probability (EPSS)
Low risk6th percentile - higher than 6% of all known CVEs
Summary
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:`.
Risk Assessment
The risk involves leveraging the application's trusted origin for phishing attacks, branded redirect abuse, and automatic redirect following by client software, potentially leading to data theft or malware infection.
Recommendation
Immediately update Shopware to version 6.7.10.1 or later, which fixes this vulnerability. As a temporary measure, consider disabling or restricting access to the `/api/oauth/sso/auth` endpoint.
Other vulnerabilities in Shopware
See all- CVE-2026-23498High
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.
- CVE-2016-3109Critical
The backend/Login/load/ script in Shopware before version 5.1.5 allows remote attackers to execute arbitrary code.
- CVE-2026-48013Medium
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.
- CVE-2026-48016Medium
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.
- CVE-2026-48015Medium
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.
- CVE-2026-48014Medium
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.
- CVE-2026-48010Medium
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.
- CVE-2026-48009Medium
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.
- CVE-2026-48008Medium
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.
- CVE-2026-48011Low
Shopware before versions 6.6.10.18 and 6.7.10.1 allows an attacker to enumerate administrator usernames via a timing attack.
Original NVD description (English source)
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.