Shopware CVE-2026-48014: Authorization Bypass in the Admin API

Published on 2 August 2026

An employee with restricted support access, a single hidden API call – and that's all it takes to cancel orders in a Shopware shop, mark them as paid or flag them as shipped. All without the permissions that would actually be required. This is exactly what the security vulnerability CVE-2026-48014 makes possible, officially published on 17 July 2026. Affected is the most widely used shop software in Germany. We explain what's behind it, who is at risk and what you need to do now.

What happened?

On 19 May 2026, Shopware quietly released two security updates (versions 6.6.10.18 and 6.7.10.1). The reason behind them was only made public on 17 July 2026 as an official vulnerability with the identifier CVE-2026-48014 in the relevant databases. The European cybersecurity agency ENISA lists it as EUVD-2026-45241.

It is a so-called authorization bypass – a flaw that lets a user do something they actually lack the permission for. Specifically: via Shopware's Admin API (the technical interface through which other programs such as ERP or fulfillment systems communicate with the shop), low-privileged user accounts can change order states even though they don't possess the intended permissions order:update, order_transaction:update or order_delivery:update.

The severity is rated with a CVSS score of 6.5 (Medium). That may sound harmless at first, but the practical significance should not be underestimated – more on that later.

The technical background – explained clearly

Shopware uses a permission system called ACL (Access Control List, a list that defines who is allowed to do what). Every API route – every endpoint you can send commands to – is supposed to declare in its metadata which permission a user needs to call it. A guardian within the system, the AclAnnotationValidator, checks with every request whether the user has the appropriate rights.

The problem: three central routes for order state transitions had simply forgotten this permission flagging. Affected are:

• /api/_action/order/{orderId}/state/{transition}
• /api/_action/order_transaction/{transactionId}/state/{transition}
• /api/_action/order_delivery/{deliveryId}/state/{transition}

And here comes the decisive error: the guardian is programmed to abort the check immediately if no permission information is present at all – following the logic "no rules defined, so I'll let it through". Experts call this fail-open behaviour: when in doubt, it opens rather than blocks. So if the ACL metadata is missing, the request is not rejected but waved through.

The database security firm SentinelOne sums it up:

"The root cause is a broken access control pattern. The route metadata decisive for ACL enforcement was never registered on the state transition endpoints. Combined with a lax validator that opens up when annotations are missing, an authorization bypass arises on every endpoint that forgets the ACL default."

Particularly explosive: as soon as the state change is triggered, Shopware executes it in the so-called SYSTEM_SCOPE – meaning the change is written to the database with system rights, without any further permission checks taking place. So an attacker needs just two things: a valid API session with any account, even a very restricted one, and a known order ID.

The security researcher who reported the vulnerability (@offset) describes the reproduction as follows:

"In real-world reproduction, the same low-privileged account receives a 403 response on the normal order update API, while the transition action API succeeds with a 200 and changes the order status in the database. The crucial point is that the reproduction is possible via direct API calls – regardless of UI access restrictions or hidden buttons."

In other words: it is not enough to simply hide the corresponding buttons in the admin area. The protection gap lies deeper, in the interface itself.

Who is affected?

According to Shopware, all installations with the following versions are affected:

• All versions before 6.6.10.18 (in the 6.6.x branch)
• Versions 6.7.0.0 up to and including 6.7.10.0 (i.e. below 6.7.10.1)

The relevance for German SMEs is enormous: according to the EHI study 2025, Shopware is for the fourth time in a row market leader among shop systems in Germany – 11.5% of the top 1,000 B2C online shops rely on it. Worldwide, according to StoreleadsApp, around 30,000 active Shopware shops are in operation, of which over 20,000 in Germany (67.2%).

Small and medium-sized retailers in particular frequently use API integrations – for example to connect ERP systems, fulfillment service providers or support tools. Any of these integration accounts that is compromised or set up with low privileges anyway can exploit the vulnerability.

How to check whether you are affected

1. Determine the Shopware version: In the admin area under Settings > System > Version information. Alternatively via the console with php bin/console --version or by searching for shopware/core in the composer.lock file.
2. Classify the version: If your version is lower than 6.6.10.18 or lies between 6.7.0.0 and 6.7.10.0, you are affected.
3. Check API users and roles: Under Settings > System > Users & permissions > Roles, review all API roles and integration accounts. Accounts with API access but without the permissions order:update, order_transaction:update or order_delivery:update could have exploited the vulnerability.
4. Look for suspicious state changes: In the database table state_machine_history, hunt for conspicuous status changes. Example query: SELECT * FROM state_machine_history WHERE created_at > '2026-01-01' ORDER BY created_at DESC LIMIT 100;
5. Analyse web server logs: In the Nginx or Apache access logs, search for POST requests to /api/_action/order/*/state/* that originate from non-privileged API users and were answered with HTTP status 200.
6. Verify the patch: After the update, check whether the file src/Core/Checkout/Order/Api/OrderActionController.php now contains the attribute PlatformRequest::ATTRIBUTE_ACL in the route definitions (commit 86dff24 or 9f15fae).

What you need to do now

The good news: the patches have been available since 19 May 2026. The update closes the vulnerability completely by adding the missing ACL declarations. Act in this order:

1. Create a backup: Before every update, make a full backup of the database and the Shopware files so you can roll back if problems arise.
2. Perform an immediate update: Update to the current version 6.6.10.21 (6.6.x branch) or 6.7.12.2 (6.7.x branch; as of 23/07/2026). The fix has been included since 6.6.10.18 or 6.7.10.1. Update via Settings > System > Shopware account > Updates or manually via Composer: composer update shopware/core shopware/platform.
3. Clean up API accounts: Review all integrations and user accounts under Settings > System > Integrations according to the least-privilege principle (each account only receives the minimum necessary rights). Accounts without a legitimate need for order management should have no API access to it at all.
4. Interim solution if an immediate update is not possible: Secure the affected routes at network level. An Nginx example:
   location ~ ^/api/_action/(order|order_transaction|order_delivery)/[^/]+/state/ { allow 10.0.0.0/8; deny all; proxy_pass http://shopware_backend; } – this way only trusted admin IP addresses are permitted. However, this is only a stopgap, not a replacement for the update.
5. Check order history: Review the state_machine_history table for unexpected changes – especially mass cancellations or sudden "paid" markings.
6. Set up monitoring: Establish centralised log monitoring for the three transition endpoints and configure alerts for HTTP 200 responses from users without order management permissions.
7. Subscribe to security advisories: Subscribe to the GitHub security advisory feed of the shopware/shopware repository to receive future updates early.

How great is the danger really?

Active attacks are so far not known. The US cybersecurity agency CISA rates the exploitation as "Exploitation=none" and "Automatable=no"; the vulnerability is not on the list of actively exploited flaws (KEV). The EPSS score – a forecast of the likelihood of exploitation within the next 30 days – is a low 0.23%.

That is no all-clear, however. Because the vulnerability is technically easy to exploit: low complexity, no user interaction, only a low-privileged account required. The possible consequences are predominantly operational in nature, as the BaseFortify CVE report notes:

"This vulnerability can lead to operational disruptions, workflow abuse and financial losses. Unauthorized users can change order states, transactions or deliveries and thereby cause fulfillment errors, billing problems or support complications."

Mass cancellations, false payment markings or manipulated shipping statuses can in practice mean considerable economic damage and reputational loss. After the update, the risk drops to zero.

GDPR: Why patching is mandatory

Even though this vulnerability does not directly expose customer data (confidentiality is not affected according to CVSS), it has a data protection dimension. Because the integrity of transaction and order data can be violated – and an unauthorized manipulation can count as a "personal data breach" under Art. 4 No. 12 GDPR.

Important for you as a controller:

• Art. 32 GDPR obliges you to take technical and organisational measures in line with the state of the art. The timely installation of available security patches is part of this. A failure to update can be assessed as a violation.
• Art. 33 GDPR requires that data breaches posing a risk to affected individuals be reported to the responsible state data protection authority within 72 hours where possible. If you demonstrably identify unauthorized state changes affecting customer or transaction data, a reporting obligation must be assessed.
• Art. 34 GDPR can additionally require notification of the affected individuals in the case of high risk.

That supervisory authorities crack down on inadequate security measures in e-commerce is shown by recent cases: in April 2026 the Spanish authority AEPD imposed a fine of 200,000 euros on AXA Seguros for inadequate security measures in a customer portal. In September 2025 the Hamburg data protection authority even imposed 492,000 euros on a financial company for inadequate technical measures.

Conclusion

CVE-2026-48014 is not a spectacular vulnerability involving stolen passwords or spied-out customer data – and yet it strikes at the heart of every online shop: the integrity of order processing. A simple API call is enough to move orders into any state with system rights, regardless of what the user interface allows.

The message is clear: if you operate a Shopware shop in one of the affected versions, update immediately to 6.6.10.21 or 6.7.12.2. Additionally, check your API accounts and order history for anomalies. Patching is not just a matter of operational security but, under Art. 32 GDPR, also a legal obligation. The effort is manageable – the potential damage from chaos in order processing, angry customers and possible fines is considerably greater.