shopware/platform

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 Problem

In src/Core/Framework/Resources/config/packages/shopware.yaml, line 194:

allowed_extensions: ["jpg", "jpeg", "png", "webp", "avif", "gif", "svg", ...]

SVG is whitelisted. The upload path (MediaUploadController → FileSaver → TypeDetector) recognizes SVG as ImageType with VECTOR_GRAPHIC flag, but no code strips JavaScript, event handlers, or external entity references from the SVG XML.

A search of the entire codebase for SVG sanitization returns — no DOMPurify, no svg-sanitize, no strip_tags on SVG content, nothing.

Impact

Stored XSS affecting all users who view the uploaded SVG. In an e-commerce context, this can lead to admin account takeover, customer data theft, or malicious plugin installation.

Suggested Fix

Either:

1. Remove SVG from allowed_extensions if SVG upload is not a core requirement
2. Sanitize SVG content on upload using a library like enshrined/svg-sanitize (strips scripts, event handlers, external references)
3. Serve SVGs with Content-Disposition: attachment to prevent inline rendering
4. Serve SVGs from a separate domain (like Nextcloud's usercontent.apps.nextcloud.com)

Option 2 is the most practical — enshrined/svg-sanitize is already used by WordPress and other PHP projects.

Regards & BG, Keyvan Hardani

Summary

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 caller owns the referenced order or has passed the required guest-order authentication. As a result, payment attempts for foreign orders are accepted by the server, which can compromise the integrity of order and payment workflows.

Description

Shopware exposes /store-api/handle-payment to initiate or retry the payment flow for an already created order. Under the normal order access model, customers should only be able to view or act on their own orders, and guest users should only be able to access guest orders after completing additional verification such as deepLinkCode, email address, and postal code. The Store API /store-api/order route follows this model: authenticated customers only see their own orders, and guest users are denied access unless guest-order authentication is performed. However, /store-api/handle-payment does not follow the same protection model. It only checks whether the supplied orderId exists and then directly forwards it into the payment processing flow. As a result, an attacker who cannot read orders through the intended protected route can still trigger the payment retry or payment initiation logic for another customer’s order as long as they know a valid foreign order ID. Although orderId is a UUID-based identifier and is not trivially guessable, it is used throughout storefront order flows such as checkout finish, account order pages, payment change flows, and download links. It is therefore a business object identifier, not a secret bearer token. The server must not treat knowledge of a valid orderId as sufficient authorization and must instead verify that the caller is entitled to act on the referenced order. This is a backend authorization flaw caused by missing ownership validation on a sensitive order action.

Expected Behavior

/store-api/handle-payment should only be available when the caller is the legitimate owner of the referenced order or, in the case of a guest order, when the required guest-order authentication has been completed. Before processing a supplied orderId, the server should verify that the current SalesChannelContext belongs to the customer associated with that order, or that the caller has successfully passed the expected guest-order verification flow. At a minimum, it should follow the same object-level authorization model used by the protected /store-api/order route.

Root Cause

The vulnerable endpoint accepts orderId, checks only that the order exists and has a currency, and then forwards it into the payment processor without any ownership validation.

#[Route(path: '/store-api/handle-payment', name: 'store-api.payment.handle', methods: ['GET', 'POST'])]
public function load(Request $request, SalesChannelContext $context): HandlePaymentMethodRouteResponse
{
    $data = [...$request->query->all(), ...$request->request->all()];
    $this->dataValidator->validate($data, $this->createDataValidation());
    /** @var array{orderId: string, finishUrl?: string, errorUrl?: string} $data */
    $orderCurrencyId = $this->getCurrencyFromOrder($data['orderId'], $context->getContext());

    if ($context->getCurrencyId() !== $orderCurrencyId) {
        $context = $this->contextService->get(
            new SalesChannelContextServiceParameters(
                $context->getSalesChannelId(),
                $context->getToken(),
                $context->getLanguageId(),
                $orderCurrencyId,
            )
        );
    }

    $response = $this->paymentProcessor->pay(
        $data['orderId'],
        $request,
        $context,
        $data['finishUrl'] ?? null,
        $data['errorUrl'] ?? null,
    );

    return new HandlePaymentMethodRouteResponse($response);
}

File: src/Core/Checkout/Payment/SalesChannel/HandlePaymentMethodRoute.php

The internal payment processing path similarly uses the supplied orderId to find the current transaction without checking whether the current caller owns the order.

public function pay(
    string $orderId,
    Request $request,
    SalesChannelContext $salesChannelContext,
    ?string $finishUrl = null,
    ?string $errorUrl = null,
): ?RedirectResponse {
    $transaction = $this->getCurrentOrderTransaction($orderId, $salesChannelContext->getContext());
    if (!$transaction) {
        return null;
    }

    $response = $paymentHandler->pay($request, $transactionStruct, $salesChannelContext->getContext(), $validationStruct);

    return $response;
}

private function getCurrentOrderTransaction(string $orderId, Context $context): ?OrderTransactionEntity
{
    $criteria = (new Criteria())
        ->addFilter(new EqualsFilter('stateId', $this->initialStateIdLoader->get(OrderTransactionStates::STATE_MACHINE)))
        ->addFilter(new EqualsFilter('orderId', $orderId))
        ->addSorting(new FieldSorting('createdAt', FieldSorting::DESCENDING))
        ->setLimit(1);

    $transaction = $this->orderTransactionRepository->search($criteria, $context)->getEntities()->first();

    if (!$transaction) {
        $criteria->resetFilters();
        $criteria->addFilter(new EqualsFilter('orderId', $orderId));

        if ($this->orderTransactionRepository->searchIds($criteria, $context)->firstId()) {
            return null;
        }

        throw PaymentException::invalidOrder($orderId);
    }

    return $transaction;
}

File: src/Core/Checkout/Payment/PaymentProcessor.php

By contrast, the official order retrieval route explicitly enforces current-context order ownership.

if ($context->getCustomer()) {
    $criteria->addFilter(new EqualsFilter('order.orderCustomer.customerId', $context->getCustomerId()));
} elseif ($deepLinkFilter === null) {
    throw OrderException::customerNotLoggedIn();
}

if ($deepLinkFilter !== null && !$context->getCustomer()) {
    $order = $orders->first();

    if ($order === null) {
        throw OrderException::guestNotAuthenticated();
    }

    $this->guestAuthenticator->validate($order, $request);
}

File: src/Core/Checkout/Order/SalesChannel/OrderRoute.php

The Store API schema also reflects that /store-api/order is designed for customer-owned or guest-authenticated order access, while /store-api/handle-payment only requires orderId.

{
  "summary": "Fetch a list of orders",
  "description": "List orders of a customer."
}

File: src/Core/Framework/Api/ApiDefinition/Generator/Schema/StoreApi/paths/order.json

{
  "summary": "Initiate a payment for an order",
  "required": ["orderId"]
}

File: src/Core/Framework/Api/ApiDefinition/Generator/Schema/StoreApi/paths/handle-payment.json

The expected model is that both order access and payment initiation are tied to order ownership or guest-order authentication. The implemented model instead trusts a caller-supplied orderId and allows a sensitive payment action on a foreign order.

Impact

The attacker only needs to be a normal remote Store API user and does not need to be an authenticated backend user. Even a guest context is sufficient. No administrator privileges, backend access, shell access, or other special internal conditions are required. In a realistic scenario, an external user can create a normal guest Store API context through the storefront or Store API and then submit a valid foreign order ID learned through another channel to /store-api/handle-payment in order to trigger the payment retry or payment initiation flow for another customer’s order. Here, orderId should not be treated as a secret authorization token. While it is not trivially guessable, it is used throughout storefront order-related flows such as checkout finish, account order detail pages, payment update routes, and download links as a business object identifier. Treating possession of a valid orderId as sufficient authorization breaks the expectation that only the legitimate order owner, or a properly authenticated guest-order user, may perform payment-related follow-up actions. In practice, this can lead to unauthorized payment attempts, external payment integration calls, customer confusion, and disruption of order processing integrity. The primary impact is on the integrity of order and payment workflows, with potential secondary operational or availability impact depending on the payment integration.

Patch Recommendation

Before processing a supplied orderId, /store-api/handle-payment should enforce the same object-level authorization model used by the order access routes. For authenticated customers, the server should verify that the order belongs to the current customer. For guest orders, it should require and validate the same guest-order authentication conditions used in the official order retrieval flow. In addition, the internal payment processor should not resolve a transaction solely by orderId; transaction lookup should be constrained to orders that are authorized for the current sales channel context and caller.

Summary

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 fulfillment/settlement/support process disruption.

Description

Shopware’s permission model requires server-side enforcement independent of UI guards. However, the dedicated order-state transition action endpoints are missing ACL metadata, so accounts without regular order update privileges can still submit transition requests that are processed by the backend. In real reproduction, the same low-privileged account receives 403 on the normal order update API, while the transition action API succeeds with 200 and updates order state in the database. The key point is that reproduction is possible through direct API calls regardless of UI access restrictions or hidden buttons. This is not a functional edge case; it is an implementation gap in authorization boundaries that enables privilege escalation behavior where a “read/limited-edit” user can control order lifecycle states.

Expected Behavior

• Order, order-transaction, and order-delivery transition endpoints must perform explicit server-side ACL checks.
• Requests should be rejected unless the caller has the proper entity update privileges, such as order:update, order_transaction:update, or order_delivery:update.
• If an account gets 403 on the normal order update API, transition actions on the same protected resource should also be blocked by equivalent policy.
• Even if transition internals use SYSTEM_SCOPE, caller authorization must be validated before entering the transition execution path.

Root Cause

File: src/Core/Checkout/Order/Api/OrderActionController.php

#[Route(
    path: '/api/_action/order/{orderId}/state/{transition}',
    name: 'api.action.order.state_machine.order.transition_state',
    methods: [Request::METHOD_POST]
)]
public function orderStateTransition(
    string $orderId,
    string $transition,
    Request $request,
    Context $context
): JsonResponse {
    $toPlace = $this->orderService->orderStateTransition(
        $orderId,
        $transition,
        $request->request,
        $context
    );

    return new JsonResponse($toPlace->jsonSerialize());
}

This route exposes state transitions but forwards user-controlled inputs (orderId, transition) into the service layer without PlatformRequest::ATTRIBUTE_ACL and without an explicit context->isAllowed(...) privilege check. An untrusted caller can directly control the transition target.

File: src/Core/Framework/Api/Acl/AclAnnotationValidator.php

$privileges = $request->attributes->get(PlatformRequest::ATTRIBUTE_ACL);

if (!$privileges) {
    return;
}

If route ACL metadata is absent, ACL validation exits immediately. Therefore these action routes skip authorization validation entirely.

File: src/Core/System/StateMachine/StateMachineRegistry.php

public function transition(Transition $transition, Context $context): StateMachineStateCollection
{
    return $context->scope(Context::SYSTEM_SCOPE, function (Context $context) use ($transition): StateMachineStateCollection {
        // ...
        $this->stateMachineHistoryRepository->create([$stateMachineHistoryEntity], $context);
        $repository->upsert($data, $context);
        // ...
    });
}

Transitions run in SYSTEM_SCOPE and persist state/history with system context. This requires strict pre-authorization at the route/controller boundary, but that pre-check is missing, so low-privileged calls still lead to real state changes.

Impact

The precondition is a remotely reachable authenticated low-privileged Admin API user (for example, operator/support account, or a compromised restricted account). The attacker only needs a valid order identifier, then calls transition action endpoints to cancel/reopen/advance order states without intended update privileges. This attack remains feasible even when UI access is restricted, because direct API calls still work. As a result, business workflows can be manipulated: order lifecycle integrity is broken, payment/shipping/document/notification/automation flows can be triggered incorrectly, and operational disruption can follow. In realistic scenarios, an attacker with a restricted account can mass-cancel or selectively alter orders, causing customer-support spikes, settlement inconsistencies, fulfillment mistakes, and practical availability degradation of day-to-day operations.

Patch Recommendation

• Add explicit ACL requirements to order/order-transaction/order-delivery transition routes in OrderActionController, aligned with entity update privileges.
• Centralize server-side privilege checks at transition entry points so transition paths and normal update paths follow consistent authorization policy.
• Keep SYSTEM_SCOPE writes strictly behind authorization gates; ensure caller privilege decisions are completed in pre-check logic before transition execution.
• Review transition-related APIs to guarantee privilege model mapping (order:*, order_transaction:*, order_delivery:*) is consistently enforced and no unprotected route remains.

Summary

There is a Proof of Concept which is able to enumerate the usernames of administrator users. This was possible by performing a timing attack.

Details

The faulty code exists in src/Core/Framework/Api/OAuth/UserRepository.php:

public function getUserEntityByUserCredentials(
        string $username,
        #[\SensitiveParameter]
        string $password,
        string $grantType,
        ClientEntityInterface $clientEntity
    ): ?UserEntityInterface {
        if ($this->loginConfigService->getConfig()?->useDefault === false) {
            // never allow login via password if the default login is disabled (e.g. using SSO only)
            return null;
        }

        $builder = $this->connection->createQueryBuilder();
        $user = $builder->select('user.id', 'user.password')
            ->from('user')
            ->where('username = :username')
            ->setParameter('username', $username)
            ->fetchAssociative();

        // PATH 1: EARLY RETURN WHEN USERNAME IS NOT FOUND
        if (!$user) {
            return null;
        }

        // PATH 2: VERIFY PASSWORD IF USER IS FOUND
        if (!password_verify($password, (string) $user['password'])) {
            return null;
        }

        return new User(Uuid::fromBytesToHex($user['id']));
    }

Subroutine getUserEntityByUserCredentials() is called when an auth request is send to api/oauth/token. If the given username is not found an early return is done (PATH 1). Only if the user is found we verify the password using password_verify.

PHP method password_verify by default uses hashing algorithm Argon2id which by design is intentionally 'slow' by introducing a timing cost to an attempt to bruteforce hashes more costly.

Since password_verify has a notable executable time, PATH 2 where an user is found and verified will be slower on average then PATH 1 where we do an early return for non-existing users.

Proposed fix

Before doing the early return, password_verify a dummy hash.

Impact

1. More targeted dictionary/bruteforce attacks.
2. Spear phishing / eases social engineering.
3. Credential stuffing from other data leaks.

Authors

Niel Duysters (@NielDuysters) and Thomas Brankaer (@tbrankaer)

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.

The Problem

In src/Core/Framework/Api/Controller/UserController.php, line 210-234:

public function upsertUser(?string $userId, Request $request, Context $context, ResponseFactoryInterface $factory): Response
{
    $data = $request->request->all(); // raw request data, no field filtering
    // ...
    $events = $context->scope(Context::SYSTEM_SCOPE, fn (Context $context) =>
        $this->userRepository->upsert([$data], $context)
    );
}

SYSTEM_SCOPE bypasses AclWriteValidator entirely (line 52 of AclWriteValidator::preValidate() returns early for SYSTEM_SCOPE). The admin boolean field is accepted without restriction.

Compare with IntegrationController::upsertIntegration() in the same codebase, which correctly checks:

if ((!$source instanceof AdminApiSource)
    || (!$source->isAdmin()
    && isset($data['admin']))
) {
    throw new PermissionDeniedException();
}

UserController is missing this exact check.

Impact

Any API user with the low-privilege user:create permission can create accounts with full admin access, or with user:update can promote any existing user to admin. This is a direct privilege escalation.

Suggested Fix

Add the same isAdmin() check from IntegrationController:

$source = $context->getSource();
if ((!$source instanceof AdminApiSource) || (!$source->isAdmin() && isset($data['admin']))) {
    throw new PermissionDeniedException();
}

Best regards, Keyvan Hardani

Summary

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 — Broken Access Control

Root Cause

The user_recovery entity exposes its hash field through the Admin API search endpoint (POST /api/search/user-recovery). The hash field lacks ApiAware(false) or ReadProtection, so any user with user_recovery:read ACL can read it.

The password recovery flow assumes the hash is delivered exclusively via email. The Admin API provides an alternative channel to obtain it, breaking this assumption.

Three endpoints combine to form the attack:

1. POST /api/_action/user/user-recovery — triggers recovery, creates hash in DB (no auth required)
2. POST /api/search/user-recovery — reads the hash (requires only user_recovery:read ACL)
3. PATCH /api/_action/user/user-recovery/password — resets password using hash (no auth required)

Vulnerable code:

• src/Core/System/User/Recovery/UserRecoveryDefinition.php — hash field is ApiAware with no ReadProtection

Impact

• Full admin account takeover — attacker gains the highest privilege level in the system
• All admin capabilities — user/role management, system configuration, plugin management, customer data access
• Cascading compromise — taken-over admin account can be used to pivot to other attacks
• Low barrier — user_recovery:read is a seemingly harmless permission that grants devastating access

Remediation

Remove the hash field from API responses:

// src/Core/System/User/Recovery/UserRecoveryDefinition.php
(new StringField('hash', 'hash'))
    ->addFlags(new Required(), new ApiAware(false)),

Summary

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 Control

Root Cause

IntegrationController::upsertIntegration() checks $source->isAdmin() before allowing the admin field to be set. However, SyncController::sync() routes writes through SyncService → EntityWriter, which only applies:

1. AclWriteValidator — checks entity-level ACL (integration:create is sufficient)
2. EntityProtectionValidator — checks WriteProtection on entity definitions, but IntegrationDefinition has none

The admin field in IntegrationDefinition is a plain BoolField with no WriteProtection or special flag. The Sync API writes it without restriction.

Vulnerable code path:

• src/Core/Framework/Api/Controller/SyncController.php → SyncService → EntityWriter::upsert()
• Missing protection: src/Core/Framework/Integration/IntegrationDefinition.php — admin field has no WriteProtection(Context::SYSTEM_SCOPE)

Working protection (bypassed):

• src/Core/Framework/Integration/IntegrationController.php:46-56 — isAdmin() check only applies to the dedicated controller endpoint

Impact

• Complete admin API access — the escalated integration has full read/write on every entity: users, customers, orders, system configuration, integrations, plugins
• PII exfiltration — read all customer records (names, emails, addresses, order history)
• Persistent backdoor — the admin integration survives password changes and user deactivation

Remediation

Add WriteProtection(Context::SYSTEM_SCOPE) to IntegrationDefinition, matching how UserDefinition and AclRoleDefinition are already protected:

// src/Core/Framework/Integration/IntegrationDefinition.php
(new BoolField('admin', 'admin'))
    ->addFlags(new WriteProtection(Context::SYSTEM_SCOPE)),

Summary

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.

Affected Scope

• All apps (public and private) that use a registrationUrl in their app manifest and rely on the legacy HMAC‑based registration flow.
• Both on‑premise and cloud installations are affected until updated to a fixed Shopware version or protected by the latest Shopware Security Plugin.
• Shopware services and first‑party apps using the affected SDKs were reviewed and patched. The vulnerability does not affect core storefront or administration authentication; it is limited to the app system’s registration and re‑registration mechanism.

Impact

In a successful attack, an attacker who already knows certain app‑side secrets could:

• Re‑register an existing app installation with a domain under their control.
• Intercept App → Shop communication and cause data tampering (“data poisoning”).
• Obtain API integration credentials of the shop with the permissions granted to the app. Shop owners and app manufacturers would typically observe this as “app malfunction” rather than an obvious security issue, which increases the need for hardening.

Root Cause

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.

Fix

We have hardened the app registration and re‑registration process:

• Dual signature requirement: Re‑registration now requires both the app secret and the existing shop secret to be presented and validated.
• Mandatory secret rotation: On successful re‑registration, a new shop secret is generated and verified; the previous secret is invalidated after a short grace period.
• Stricter validation: Shopware only accepts updated shop URLs and secrets once the full confirmation flow has completed successfully.
• Improved logging and monitoring: All re‑registrations are now logged with additional metadata to help detect abuse patterns. These changes are delivered via:
• Updated Shopware core releases (6.6.x, 6.7.x), and
• Updated versions of the Shopware Security Plugin for supported older versions,
• Updated official SDKs (e.g. PHP and JavaScript app SDKs).

Required Action

For Merchants / Shop Operators

1. Update Shopware
   • Upgrade to the latest Shopware 6.6.x / 6.7.x release that includes this fix, or
   • Install/update the latest Shopware Security Plugin version providing the hotfix for your Shopware 6 installation.
2. Update apps
   • Ensure all installed apps are updated to the latest versions provided by their manufacturers.
   • If you suspect compromised keys or observe unexpected app behaviour, re‑install the affected app or trigger key rotation as documented by the app vendor.

For App Manufacturers / Partners

1. Update SDKs / implementations
   • Update to the latest Shopware app SDKs (PHP / JS) or apply the documented changes if you maintain a custom implementation of the registration flow.
   • Validate both shopware-app-signature and shopware-shop-signature for re‑registration requests.
   • Always generate and store a new shop secret on re‑registration and only switch to it after a successful confirmation.
2. Review your apps
   • Verify that your app does not blindly accept changed shop-url values without validating signatures.
   • Check any logic that exposes data or functionality based solely on HMAC signatures from shops and ensure it aligns with the hardened registration model.
3. Test your implementation
   • Use the updated tooling and guidance provided in your Shopware Account / partner channels to validate that your registration flow complies with the new requirements.

Summary

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.

CWE

• CWE-204: Observable Response Discrepancy

Description

Distinct error codes leak account existence

The login flow in AccountService::getCustomerByLogin() calls getCustomerByEmail() first, which throws CustomerNotFoundException if the email is not found. If the email IS found but the password is wrong, a separate BadCredentialsException is thrown:

// src/Core/Checkout/Customer/SalesChannel/AccountService.php:116-145
public function getCustomerByLogin(string $email, string $password, SalesChannelContext $context): CustomerEntity
{
    if ($this->isPasswordTooLong($password)) {
        throw CustomerException::badCredentials();
    }

    $customer = $this->getCustomerByEmail($email, $context);
    // ↑ Throws CustomerNotFoundException with CHECKOUT__CUSTOMER_NOT_FOUND if email unknown

    if ($customer->hasLegacyPassword()) {
        if (!$this->legacyPasswordVerifier->verify($password, $customer)) {
            throw CustomerException::badCredentials();
            // ↑ Throws BadCredentialsException with CHECKOUT__CUSTOMER_AUTH_BAD_CREDENTIALS
        }
        // ...
    }

    if ($customer->getPassword() === null
        || !password_verify($password, $customer->getPassword())) {
        throw CustomerException::badCredentials();
        // ↑ Same: CHECKOUT__CUSTOMER_AUTH_BAD_CREDENTIALS
    }
    // ...
}

The two exception types produce clearly distinguishable API responses:

Email not registered:

{
  "errors": [{
    "status": "401",
    "code": "CHECKOUT__CUSTOMER_NOT_FOUND",
    "detail": "No matching customer for the email \"probe@example.com\" was found.",
    "meta": { "parameters": { "email": "probe@example.com" } }
  }]
}

Email registered, wrong password:

{
  "errors": [{
    "status": "401",
    "code": "CHECKOUT__CUSTOMER_AUTH_BAD_CREDENTIALS",
    "detail": "Invalid username and/or password."
  }]
}

Storefront is protected — Store API is not

The storefront login controller demonstrates that Shopware's developers are aware of this risk class. AuthController::login() catches both exceptions together and returns a generic error:

// src/Storefront/Controller/AuthController.php:203
} catch (BadCredentialsException|CustomerNotFoundException) {
    // Unified handling — no distinction exposed to the user
}

The Store API LoginRoute::login() does NOT catch these exceptions. They propagate to the global ErrorResponseFactory, which serializes the distinct error codes into the JSON response:

// src/Core/Checkout/Customer/SalesChannel/LoginRoute.php:54-58
$token = $this->accountService->loginByCredentials(
    $email,
    (string) $data->get('password'),
    $context
);
// No try/catch — exceptions propagate with distinct codes

This inconsistency confirms the Store API exposure is an oversight, not a design decision.

Rate limiting is present but insufficient for enumeration

The login route has rate limiting (LoginRoute.php:47-51) keyed on strtolower($email) . '-' . $clientIp. This slows bulk enumeration but does not prevent it because:

1. The attacker only needs one request per email to determine existence
2. The rate limit key includes the IP, so rotating IPs resets the counter
3. The rate limiter is designed to prevent brute-force password guessing, not single-probe enumeration

Impact

• Customer email enumeration: An attacker can confirm whether specific email addresses are registered as customers, enabling targeted attacks
• Phishing enablement: Confirmed customer emails can be targeted with store-specific phishing campaigns (e.g., fake order confirmations, password reset lures)
• Credential stuffing optimization: Attackers with breached credential databases can first filter for valid emails before attempting password guesses, improving efficiency against rate limits
• Privacy violation: Confirms an individual's association with a specific store, which may be sensitive depending on the store's nature (e.g., medical supplies, adult products)
• Email reflection: The CHECKOUT__CUSTOMER_NOT_FOUND response echoes the probed email in the detail and meta.parameters.email fields, which could be leveraged in reflected content attacks

Recommended Remediation

Option 1: Catch both exceptions in LoginRoute and throw a unified error (Preferred)

Apply the same pattern already used in the storefront controller:

// src/Core/Checkout/Customer/SalesChannel/LoginRoute.php
public function login(#[\SensitiveParameter] RequestDataBag $data, SalesChannelContext $context): ContextTokenResponse
{
    EmailIdnConverter::encodeDataBag($data);
    $email = (string) $data->get('email', $data->get('username'));

    if ($this->requestStack->getMainRequest() !== null) {
        $cacheKey = strtolower($email) . '-' . $this->requestStack->getMainRequest()->getClientIp();

        try {
            $this->rateLimiter->ensureAccepted(RateLimiter::LOGIN_ROUTE, $cacheKey);
        } catch (RateLimitExceededException $exception) {
            throw CustomerException::customerAuthThrottledException($exception->getWaitTime(), $exception);
        }
    }

    try {
        $token = $this->accountService->loginByCredentials(
            $email,
            (string) $data->get('password'),
            $context
        );
    } catch (CustomerNotFoundException) {
        // Normalize to the same exception as bad credentials
        throw CustomerException::badCredentials();
    }

    if (isset($cacheKey)) {
        $this->rateLimiter->reset(RateLimiter::LOGIN_ROUTE, $cacheKey);
    }

    return new ContextTokenResponse($token);
}

This ensures both "not found" and "bad credentials" return the same CHECKOUT__CUSTOMER_AUTH_BAD_CREDENTIALS code and generic message.

Option 2: Unify at the AccountService layer

For defense in depth, change AccountService::getCustomerByLogin() to throw BadCredentialsException instead of letting CustomerNotFoundException propagate:

// src/Core/Checkout/Customer/SalesChannel/AccountService.php
public function getCustomerByLogin(string $email, string $password, SalesChannelContext $context): CustomerEntity
{
    if ($this->isPasswordTooLong($password)) {
        throw CustomerException::badCredentials();
    }

    try {
        $customer = $this->getCustomerByEmail($email, $context);
    } catch (CustomerNotFoundException) {
        throw CustomerException::badCredentials();
    }

    // ... rest of password verification
}

This protects all callers of getCustomerByLogin() regardless of how they handle exceptions. Note: getCustomerByEmail() is also called independently (e.g., password recovery), so that method should continue to throw CustomerNotFoundException for internal use — the normalization should happen at the login boundary.

Additional: Fix registration endpoint

The registration endpoint (POST /store-api/account/register) also leaks email existence via CUSTOMER_EMAIL_NOT_UNIQUE. For complete remediation, consider returning a generic success response and sending a notification email to the existing address instead.

Credit

This vulnerability was discovered and reported by bugbunny.ai.

Summary

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.

Details

Data Exposure

Depending on the order payload configuration, attackers may retrieve:

• Customer names
• Billing address
• Shipping address
• Email addresses
• Ordered products
• Order values
• Order numbers
• Order dates
• Payment method information
• Shipping method information
• More customs, depending on the given associations in the request

Security Impact

This vulnerability allows:

• Unauthorized access to foreign customer order data
• Mass enumeration of recent orders
• Potential scraping of customer personal information

Limitation

No limitation, but only orders from the past 30 days are checked for changeable means of payment (unrelated).

Impact

The code is present since ~2021. Likely every version since then is impacted for every store.

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.

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 information disclosure occurs when an application inadvertently displays sensitive information to its users. Depending on the context, websites can leak all kinds of information including: • Data regarding other users, such as usernames and/or e-mail addresses • Sensitive commercial data such as customer names • Technical details about the website and/or the underlying infrastructure Disclosing technical details, such as detailed version information, allows malicious actors to look for targeted vulnerabilities and/or misconfigurations in the application or in the underlying infrastructure. In addition, an application is more likely to be targeted by attacks that specifically target a particular version of the software used.

Applicability

The Shopware application exposes sensitive information to users within the export section. The Shopware application allows admins to import and export data within the application. To do this import/export profiles can be created. These profiles tell the application which tables within the database map to which columns in the generated file. During testing it was noticed that sensitive information such as password hashes or reset codes can also be included within the export. This can be done by creating a custom mapping that includes these fields within the export. To exploit this vulnerability, an account with permissions to create import/export profiles and to create exports, is required.

Reproduction

To reproduce this vulnerability, the steps below can be followed.

1. Log in to Shopware application with an admin account capable of creating import/export profiles and creating exports
2. Create a new import/export profile
3. Add a new mapping for the ‘password’ database entry
4. Create an export using the new profile
5. Notice that the password hashes of the users are available within the export file.

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 domains. SSRF is commonly exploited to make the server initiate requests to its internal systems or other services within the same network, which are typically not exposed to external users. In some cases, SSRF can also be used to target external systems. A successful SSRF attack can result in unauthorized actions or access to data within the organization, the web application itself, or other backend systems the application communicates with. In worst-case scenario, a SSRF vulnerability can be exploited to execute malicious code on the server.

Applicability

The PDF generator used to create order invoices contains a Server-Side Request Forgery (SSRF) vulnerability. Administrative users can generate invoices for completed orders and have the option to add a note to the invoice. This input is currently not adequately filtered for (malicious) HTML characters. When a malicious actor submits an IMG tag as input, the PDF generator attempts to retrieve an external image while processing the IMG tag. As a result, the application server can be used to perform an HTTP request, enabling the malicious actors to reach both external and internal servers. To exploit this vulnerability, an admin account is required.

Reproduction

To reproduce this vulnerability, the steps below can be followed.

1. Log in as an admin and navigate to the following URL: https://.shopware.store/admin#/sw/order/detail/0198e0afa2cb70ceb76ad64fc7864ca6/documents?limit=25&page=1&term=&sortBy&sortDirection=ASC&naturalSorting=false
2. Click the button ‘Create document’ and create a ‘Partial cancellation’ document.
3. As a comment add the following code:

<img src="<malicious image link>" width="250" height="100"/>

4. Press the preview button to view the PFD.
5. Observe that the image is shown in the PDF.

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 affected function. This vulnerability occurs when an application uses unfiltered user input to point to the path of a specific file and retrieve it. This can result in gaining read/write access to sensitive information, application code, back-end systems and other (critical) files on the operating system. In certain cases, it is even possible to store arbitrary files outside the relevant directory structure on the server in order to gain access to the server.

Applicability

The Plugin upload function in use by the Shopware application is vulnerable to path traversal. Within the on-premises version of the Shopware application users are able to extend the functionality of the application by installing ‘plugins’ also referred to as ‘apps’ or ‘extensions’. These plugins can be installed using the official store or by uploading a zip file containing the required files. To prevent path traversal the Shopware application implements a check that effectively prohibits files containing ‘..’ characters from being uploaded. During review of the source code, it was noticed that the check for the prohibited characters was only performed from the third entry (index 2) of the uploaded Zip file. This means that the second entry (index 1) within the Zip file can contain path traversal characters and thus allows files to be written in directories outside of the intended plugins folder.

To exploit this vulnerability, an admin account with permissions to upload plugins, is required.

Reproduction

To reproduce this vulnerability, the steps below can be followed.

1. Log in to an on-premises Shopware application with an admin account with permissions to upload plugins.
2. Create a malicious Zip file using the script provided in evidence 5.
3. Upload the generated malicious Zip file as a new plugin within the application
4. Access the filesystem of the Shopware application
5. Navigate to the path below: /var/www/html/custom/apps
6. Notice that an ‘evil.php’ file has been extracted within this folder.

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 within associated private media. The issue is resolved in 6.6.10.7 and 6.7.3.1.

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.

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 Problem

In src/Core/Framework/Resources/config/packages/shopware.yaml, line 194:

allowed_extensions: ["jpg", "jpeg", "png", "webp", "avif", "gif", "svg", ...]

SVG is whitelisted. The upload path (MediaUploadController → FileSaver → TypeDetector) recognizes SVG as ImageType with VECTOR_GRAPHIC flag, but no code strips JavaScript, event handlers, or external entity references from the SVG XML.

A search of the entire codebase for SVG sanitization returns — no DOMPurify, no svg-sanitize, no strip_tags on SVG content, nothing.

Impact

Stored XSS affecting all users who view the uploaded SVG. In an e-commerce context, this can lead to admin account takeover, customer data theft, or malicious plugin installation.

Suggested Fix

Either:

1. Remove SVG from allowed_extensions if SVG upload is not a core requirement
2. Sanitize SVG content on upload using a library like enshrined/svg-sanitize (strips scripts, event handlers, external references)
3. Serve SVGs with Content-Disposition: attachment to prevent inline rendering
4. Serve SVGs from a separate domain (like Nextcloud's usercontent.apps.nextcloud.com)

Option 2 is the most practical — enshrined/svg-sanitize is already used by WordPress and other PHP projects.

Regards & BG, Keyvan Hardani

Summary

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 caller owns the referenced order or has passed the required guest-order authentication. As a result, payment attempts for foreign orders are accepted by the server, which can compromise the integrity of order and payment workflows.

Description

Shopware exposes /store-api/handle-payment to initiate or retry the payment flow for an already created order. Under the normal order access model, customers should only be able to view or act on their own orders, and guest users should only be able to access guest orders after completing additional verification such as deepLinkCode, email address, and postal code. The Store API /store-api/order route follows this model: authenticated customers only see their own orders, and guest users are denied access unless guest-order authentication is performed. However, /store-api/handle-payment does not follow the same protection model. It only checks whether the supplied orderId exists and then directly forwards it into the payment processing flow. As a result, an attacker who cannot read orders through the intended protected route can still trigger the payment retry or payment initiation logic for another customer’s order as long as they know a valid foreign order ID. Although orderId is a UUID-based identifier and is not trivially guessable, it is used throughout storefront order flows such as checkout finish, account order pages, payment change flows, and download links. It is therefore a business object identifier, not a secret bearer token. The server must not treat knowledge of a valid orderId as sufficient authorization and must instead verify that the caller is entitled to act on the referenced order. This is a backend authorization flaw caused by missing ownership validation on a sensitive order action.

Expected Behavior

/store-api/handle-payment should only be available when the caller is the legitimate owner of the referenced order or, in the case of a guest order, when the required guest-order authentication has been completed. Before processing a supplied orderId, the server should verify that the current SalesChannelContext belongs to the customer associated with that order, or that the caller has successfully passed the expected guest-order verification flow. At a minimum, it should follow the same object-level authorization model used by the protected /store-api/order route.

Root Cause

The vulnerable endpoint accepts orderId, checks only that the order exists and has a currency, and then forwards it into the payment processor without any ownership validation.

#[Route(path: '/store-api/handle-payment', name: 'store-api.payment.handle', methods: ['GET', 'POST'])]
public function load(Request $request, SalesChannelContext $context): HandlePaymentMethodRouteResponse
{
    $data = [...$request->query->all(), ...$request->request->all()];
    $this->dataValidator->validate($data, $this->createDataValidation());
    /** @var array{orderId: string, finishUrl?: string, errorUrl?: string} $data */
    $orderCurrencyId = $this->getCurrencyFromOrder($data['orderId'], $context->getContext());

    if ($context->getCurrencyId() !== $orderCurrencyId) {
        $context = $this->contextService->get(
            new SalesChannelContextServiceParameters(
                $context->getSalesChannelId(),
                $context->getToken(),
                $context->getLanguageId(),
                $orderCurrencyId,
            )
        );
    }

    $response = $this->paymentProcessor->pay(
        $data['orderId'],
        $request,
        $context,
        $data['finishUrl'] ?? null,
        $data['errorUrl'] ?? null,
    );

    return new HandlePaymentMethodRouteResponse($response);
}

File: src/Core/Checkout/Payment/SalesChannel/HandlePaymentMethodRoute.php

The internal payment processing path similarly uses the supplied orderId to find the current transaction without checking whether the current caller owns the order.

public function pay(
    string $orderId,
    Request $request,
    SalesChannelContext $salesChannelContext,
    ?string $finishUrl = null,
    ?string $errorUrl = null,
): ?RedirectResponse {
    $transaction = $this->getCurrentOrderTransaction($orderId, $salesChannelContext->getContext());
    if (!$transaction) {
        return null;
    }

    $response = $paymentHandler->pay($request, $transactionStruct, $salesChannelContext->getContext(), $validationStruct);

    return $response;
}

private function getCurrentOrderTransaction(string $orderId, Context $context): ?OrderTransactionEntity
{
    $criteria = (new Criteria())
        ->addFilter(new EqualsFilter('stateId', $this->initialStateIdLoader->get(OrderTransactionStates::STATE_MACHINE)))
        ->addFilter(new EqualsFilter('orderId', $orderId))
        ->addSorting(new FieldSorting('createdAt', FieldSorting::DESCENDING))
        ->setLimit(1);

    $transaction = $this->orderTransactionRepository->search($criteria, $context)->getEntities()->first();

    if (!$transaction) {
        $criteria->resetFilters();
        $criteria->addFilter(new EqualsFilter('orderId', $orderId));

        if ($this->orderTransactionRepository->searchIds($criteria, $context)->firstId()) {
            return null;
        }

        throw PaymentException::invalidOrder($orderId);
    }

    return $transaction;
}

File: src/Core/Checkout/Payment/PaymentProcessor.php

By contrast, the official order retrieval route explicitly enforces current-context order ownership.

if ($context->getCustomer()) {
    $criteria->addFilter(new EqualsFilter('order.orderCustomer.customerId', $context->getCustomerId()));
} elseif ($deepLinkFilter === null) {
    throw OrderException::customerNotLoggedIn();
}

if ($deepLinkFilter !== null && !$context->getCustomer()) {
    $order = $orders->first();

    if ($order === null) {
        throw OrderException::guestNotAuthenticated();
    }

    $this->guestAuthenticator->validate($order, $request);
}

File: src/Core/Checkout/Order/SalesChannel/OrderRoute.php

The Store API schema also reflects that /store-api/order is designed for customer-owned or guest-authenticated order access, while /store-api/handle-payment only requires orderId.

{
  "summary": "Fetch a list of orders",
  "description": "List orders of a customer."
}

File: src/Core/Framework/Api/ApiDefinition/Generator/Schema/StoreApi/paths/order.json

{
  "summary": "Initiate a payment for an order",
  "required": ["orderId"]
}

File: src/Core/Framework/Api/ApiDefinition/Generator/Schema/StoreApi/paths/handle-payment.json

The expected model is that both order access and payment initiation are tied to order ownership or guest-order authentication. The implemented model instead trusts a caller-supplied orderId and allows a sensitive payment action on a foreign order.

Impact

The attacker only needs to be a normal remote Store API user and does not need to be an authenticated backend user. Even a guest context is sufficient. No administrator privileges, backend access, shell access, or other special internal conditions are required. In a realistic scenario, an external user can create a normal guest Store API context through the storefront or Store API and then submit a valid foreign order ID learned through another channel to /store-api/handle-payment in order to trigger the payment retry or payment initiation flow for another customer’s order. Here, orderId should not be treated as a secret authorization token. While it is not trivially guessable, it is used throughout storefront order-related flows such as checkout finish, account order detail pages, payment update routes, and download links as a business object identifier. Treating possession of a valid orderId as sufficient authorization breaks the expectation that only the legitimate order owner, or a properly authenticated guest-order user, may perform payment-related follow-up actions. In practice, this can lead to unauthorized payment attempts, external payment integration calls, customer confusion, and disruption of order processing integrity. The primary impact is on the integrity of order and payment workflows, with potential secondary operational or availability impact depending on the payment integration.

Patch Recommendation

Before processing a supplied orderId, /store-api/handle-payment should enforce the same object-level authorization model used by the order access routes. For authenticated customers, the server should verify that the order belongs to the current customer. For guest orders, it should require and validate the same guest-order authentication conditions used in the official order retrieval flow. In addition, the internal payment processor should not resolve a transaction solely by orderId; transaction lookup should be constrained to orders that are authorized for the current sales channel context and caller.

Summary

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 fulfillment/settlement/support process disruption.

Description

Shopware’s permission model requires server-side enforcement independent of UI guards. However, the dedicated order-state transition action endpoints are missing ACL metadata, so accounts without regular order update privileges can still submit transition requests that are processed by the backend. In real reproduction, the same low-privileged account receives 403 on the normal order update API, while the transition action API succeeds with 200 and updates order state in the database. The key point is that reproduction is possible through direct API calls regardless of UI access restrictions or hidden buttons. This is not a functional edge case; it is an implementation gap in authorization boundaries that enables privilege escalation behavior where a “read/limited-edit” user can control order lifecycle states.

Expected Behavior

• Order, order-transaction, and order-delivery transition endpoints must perform explicit server-side ACL checks.
• Requests should be rejected unless the caller has the proper entity update privileges, such as order:update, order_transaction:update, or order_delivery:update.
• If an account gets 403 on the normal order update API, transition actions on the same protected resource should also be blocked by equivalent policy.
• Even if transition internals use SYSTEM_SCOPE, caller authorization must be validated before entering the transition execution path.

Root Cause

File: src/Core/Checkout/Order/Api/OrderActionController.php

#[Route(
    path: '/api/_action/order/{orderId}/state/{transition}',
    name: 'api.action.order.state_machine.order.transition_state',
    methods: [Request::METHOD_POST]
)]
public function orderStateTransition(
    string $orderId,
    string $transition,
    Request $request,
    Context $context
): JsonResponse {
    $toPlace = $this->orderService->orderStateTransition(
        $orderId,
        $transition,
        $request->request,
        $context
    );

    return new JsonResponse($toPlace->jsonSerialize());
}

This route exposes state transitions but forwards user-controlled inputs (orderId, transition) into the service layer without PlatformRequest::ATTRIBUTE_ACL and without an explicit context->isAllowed(...) privilege check. An untrusted caller can directly control the transition target.

File: src/Core/Framework/Api/Acl/AclAnnotationValidator.php

$privileges = $request->attributes->get(PlatformRequest::ATTRIBUTE_ACL);

if (!$privileges) {
    return;
}

If route ACL metadata is absent, ACL validation exits immediately. Therefore these action routes skip authorization validation entirely.

File: src/Core/System/StateMachine/StateMachineRegistry.php

public function transition(Transition $transition, Context $context): StateMachineStateCollection
{
    return $context->scope(Context::SYSTEM_SCOPE, function (Context $context) use ($transition): StateMachineStateCollection {
        // ...
        $this->stateMachineHistoryRepository->create([$stateMachineHistoryEntity], $context);
        $repository->upsert($data, $context);
        // ...
    });
}

Transitions run in SYSTEM_SCOPE and persist state/history with system context. This requires strict pre-authorization at the route/controller boundary, but that pre-check is missing, so low-privileged calls still lead to real state changes.

Impact

The precondition is a remotely reachable authenticated low-privileged Admin API user (for example, operator/support account, or a compromised restricted account). The attacker only needs a valid order identifier, then calls transition action endpoints to cancel/reopen/advance order states without intended update privileges. This attack remains feasible even when UI access is restricted, because direct API calls still work. As a result, business workflows can be manipulated: order lifecycle integrity is broken, payment/shipping/document/notification/automation flows can be triggered incorrectly, and operational disruption can follow. In realistic scenarios, an attacker with a restricted account can mass-cancel or selectively alter orders, causing customer-support spikes, settlement inconsistencies, fulfillment mistakes, and practical availability degradation of day-to-day operations.

Patch Recommendation

• Add explicit ACL requirements to order/order-transaction/order-delivery transition routes in OrderActionController, aligned with entity update privileges.
• Centralize server-side privilege checks at transition entry points so transition paths and normal update paths follow consistent authorization policy.
• Keep SYSTEM_SCOPE writes strictly behind authorization gates; ensure caller privilege decisions are completed in pre-check logic before transition execution.
• Review transition-related APIs to guarantee privilege model mapping (order:*, order_transaction:*, order_delivery:*) is consistently enforced and no unprotected route remains.

Summary

There is a Proof of Concept which is able to enumerate the usernames of administrator users. This was possible by performing a timing attack.

Details

The faulty code exists in src/Core/Framework/Api/OAuth/UserRepository.php:

public function getUserEntityByUserCredentials(
        string $username,
        #[\SensitiveParameter]
        string $password,
        string $grantType,
        ClientEntityInterface $clientEntity
    ): ?UserEntityInterface {
        if ($this->loginConfigService->getConfig()?->useDefault === false) {
            // never allow login via password if the default login is disabled (e.g. using SSO only)
            return null;
        }

        $builder = $this->connection->createQueryBuilder();
        $user = $builder->select('user.id', 'user.password')
            ->from('user')
            ->where('username = :username')
            ->setParameter('username', $username)
            ->fetchAssociative();

        // PATH 1: EARLY RETURN WHEN USERNAME IS NOT FOUND
        if (!$user) {
            return null;
        }

        // PATH 2: VERIFY PASSWORD IF USER IS FOUND
        if (!password_verify($password, (string) $user['password'])) {
            return null;
        }

        return new User(Uuid::fromBytesToHex($user['id']));
    }

Subroutine getUserEntityByUserCredentials() is called when an auth request is send to api/oauth/token. If the given username is not found an early return is done (PATH 1). Only if the user is found we verify the password using password_verify.

PHP method password_verify by default uses hashing algorithm Argon2id which by design is intentionally 'slow' by introducing a timing cost to an attempt to bruteforce hashes more costly.

Since password_verify has a notable executable time, PATH 2 where an user is found and verified will be slower on average then PATH 1 where we do an early return for non-existing users.

Proposed fix

Before doing the early return, password_verify a dummy hash.

Impact

1. More targeted dictionary/bruteforce attacks.
2. Spear phishing / eases social engineering.
3. Credential stuffing from other data leaks.

Authors

Niel Duysters (@NielDuysters) and Thomas Brankaer (@tbrankaer)

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.

The Problem

In src/Core/Framework/Api/Controller/UserController.php, line 210-234:

public function upsertUser(?string $userId, Request $request, Context $context, ResponseFactoryInterface $factory): Response
{
    $data = $request->request->all(); // raw request data, no field filtering
    // ...
    $events = $context->scope(Context::SYSTEM_SCOPE, fn (Context $context) =>
        $this->userRepository->upsert([$data], $context)
    );
}

SYSTEM_SCOPE bypasses AclWriteValidator entirely (line 52 of AclWriteValidator::preValidate() returns early for SYSTEM_SCOPE). The admin boolean field is accepted without restriction.

Compare with IntegrationController::upsertIntegration() in the same codebase, which correctly checks:

if ((!$source instanceof AdminApiSource)
    || (!$source->isAdmin()
    && isset($data['admin']))
) {
    throw new PermissionDeniedException();
}

UserController is missing this exact check.

Impact

Any API user with the low-privilege user:create permission can create accounts with full admin access, or with user:update can promote any existing user to admin. This is a direct privilege escalation.

Suggested Fix

Add the same isAdmin() check from IntegrationController:

$source = $context->getSource();
if ((!$source instanceof AdminApiSource) || (!$source->isAdmin() && isset($data['admin']))) {
    throw new PermissionDeniedException();
}

Best regards, Keyvan Hardani

Summary

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 — Broken Access Control

Root Cause

The user_recovery entity exposes its hash field through the Admin API search endpoint (POST /api/search/user-recovery). The hash field lacks ApiAware(false) or ReadProtection, so any user with user_recovery:read ACL can read it.

The password recovery flow assumes the hash is delivered exclusively via email. The Admin API provides an alternative channel to obtain it, breaking this assumption.

Three endpoints combine to form the attack:

1. POST /api/_action/user/user-recovery — triggers recovery, creates hash in DB (no auth required)
2. POST /api/search/user-recovery — reads the hash (requires only user_recovery:read ACL)
3. PATCH /api/_action/user/user-recovery/password — resets password using hash (no auth required)

Vulnerable code:

• src/Core/System/User/Recovery/UserRecoveryDefinition.php — hash field is ApiAware with no ReadProtection

Impact

• Full admin account takeover — attacker gains the highest privilege level in the system
• All admin capabilities — user/role management, system configuration, plugin management, customer data access
• Cascading compromise — taken-over admin account can be used to pivot to other attacks
• Low barrier — user_recovery:read is a seemingly harmless permission that grants devastating access

Remediation

Remove the hash field from API responses:

// src/Core/System/User/Recovery/UserRecoveryDefinition.php
(new StringField('hash', 'hash'))
    ->addFlags(new Required(), new ApiAware(false)),

Summary

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 Control

Root Cause

IntegrationController::upsertIntegration() checks $source->isAdmin() before allowing the admin field to be set. However, SyncController::sync() routes writes through SyncService → EntityWriter, which only applies:

1. AclWriteValidator — checks entity-level ACL (integration:create is sufficient)
2. EntityProtectionValidator — checks WriteProtection on entity definitions, but IntegrationDefinition has none

The admin field in IntegrationDefinition is a plain BoolField with no WriteProtection or special flag. The Sync API writes it without restriction.

Vulnerable code path:

• src/Core/Framework/Api/Controller/SyncController.php → SyncService → EntityWriter::upsert()
• Missing protection: src/Core/Framework/Integration/IntegrationDefinition.php — admin field has no WriteProtection(Context::SYSTEM_SCOPE)

Working protection (bypassed):

• src/Core/Framework/Integration/IntegrationController.php:46-56 — isAdmin() check only applies to the dedicated controller endpoint

Impact

• Complete admin API access — the escalated integration has full read/write on every entity: users, customers, orders, system configuration, integrations, plugins
• PII exfiltration — read all customer records (names, emails, addresses, order history)
• Persistent backdoor — the admin integration survives password changes and user deactivation

Remediation

Add WriteProtection(Context::SYSTEM_SCOPE) to IntegrationDefinition, matching how UserDefinition and AclRoleDefinition are already protected:

// src/Core/Framework/Integration/IntegrationDefinition.php
(new BoolField('admin', 'admin'))
    ->addFlags(new WriteProtection(Context::SYSTEM_SCOPE)),

Summary

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.

Details

The vulnerability is an inconsistency between two URL-handling flows in MediaUploadService.

Vulnerable path (external-link):

MediaUploadV2Controller::externalLink() at src/Core/Content/Media/Api/MediaUploadV2Controller.php:66 takes a user-supplied url parameter and passes it to MediaUploadService::linkURL() at src/Core/Content/Media/Upload/MediaUploadService.php:134.

linkURL() calls getContentSizeFromValidExternalUrl($url) at line 159, which only validates via validateExternalUrl():

// src/Core/Content/Media/Upload/MediaUploadService.php:207-212
public static function validateExternalUrl(string $url): void
{
    if (!preg_match('/^https?:\/\/.+/', $url)) {
        throw MediaException::invalidUrl($url);
    }
}

Then makes a server-side HEAD request with no IP filtering:

// src/Core/Content/Media/Upload/MediaUploadService.php:292-300
private function getContentSizeFromValidExternalUrl(string $url): int
{
    $this->validateExternalUrl($url);

    $headers = $this->httpClient->request('HEAD', $url)->getHeaders();
    if (!\array_key_exists('content-length', $headers)) {
        throw MediaException::fileNotFound($url);
    }

    return (int) $headers['content-length'][0];
}

Protected path (upload_by_url):

In contrast, uploadFromURL uses FileFetcher::fetchFromURL() which calls FileUrlValidator::isValid():

// src/Core/Content/Media/File/FileFetcher.php:64
if ($this->enableUrlValidation && !$this->fileUrlValidator->isValid($url)) {
    throw MediaException::illegalUrl($url);
}

FileUrlValidator::isValid() resolves the hostname via gethostbyname() and validates the IP against private and reserved ranges using filter_var() with FILTER_FLAG_NO_PRIV_RANGE | FILTER_FLAG_NO_RES_RANGE. This protection is entirely absent from the linkURL flow.

Impact

An authenticated admin user can:

1. Probe cloud metadata services — HEAD requests to 169.254.169.254 reveal whether cloud metadata endpoints exist and leak content-length values
2. Scan internal networks — Differentiate open/closed/filtered ports on internal hosts (10.x, 172.16.x, 192.168.x) based on response timing and error types
3. Leak internal service information — The fileSize field stored in the database reflects the content-length header from internal services
4. Redirect-based escalation — Symfony HttpClient follows redirects by default (max_redirects=20), allowing an attacker-controlled external server to redirect the HEAD request to arbitrary internal destinations

Impact is limited to information disclosure via HEAD requests. The admin authentication requirement (PR:H) reduces exploitability, but in multi-tenant or compromised-credential scenarios this allows network reconnaissance from the server's perspective.

Recommended Fix

Apply FileUrlValidator to the linkURL flow, consistent with the uploadFromURL flow. In MediaUploadService:

// src/Core/Content/Media/Upload/MediaUploadService.php

// Add constructor dependency:
private readonly FileUrlValidatorInterface $fileUrlValidator;

// In getContentSizeFromValidExternalUrl(), add IP validation:
private function getContentSizeFromValidExternalUrl(string $url): int
{
    $this->validateExternalUrl($url);

    if (!$this->fileUrlValidator->isValid($url)) {
        throw MediaException::illegalUrl($url);
    }

    $headers = $this->httpClient->request('HEAD', $url)->getHeaders();
    if (!\array_key_exists('content-length', $headers)) {
        throw MediaException::fileNotFound($url);
    }

    return (int) $headers['content-length'][0];
}

Additionally, consider setting max_redirects: 0 on the HttpClient request to prevent redirect-based SSRF bypasses.

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 Problem

In src/Core/Framework/Resources/config/packages/shopware.yaml, line 194:

allowed_extensions: ["jpg", "jpeg", "png", "webp", "avif", "gif", "svg", ...]

SVG is whitelisted. The upload path (MediaUploadController → FileSaver → TypeDetector) recognizes SVG as ImageType with VECTOR_GRAPHIC flag, but no code strips JavaScript, event handlers, or external entity references from the SVG XML.

A search of the entire codebase for SVG sanitization returns — no DOMPurify, no svg-sanitize, no strip_tags on SVG content, nothing.

Impact

Stored XSS affecting all users who view the uploaded SVG. In an e-commerce context, this can lead to admin account takeover, customer data theft, or malicious plugin installation.

Suggested Fix

Either:

1. Remove SVG from allowed_extensions if SVG upload is not a core requirement
2. Sanitize SVG content on upload using a library like enshrined/svg-sanitize (strips scripts, event handlers, external references)
3. Serve SVGs with Content-Disposition: attachment to prevent inline rendering
4. Serve SVGs from a separate domain (like Nextcloud's usercontent.apps.nextcloud.com)

Option 2 is the most practical — enshrined/svg-sanitize is already used by WordPress and other PHP projects.

Regards & BG, Keyvan Hardani

Summary

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 caller owns the referenced order or has passed the required guest-order authentication. As a result, payment attempts for foreign orders are accepted by the server, which can compromise the integrity of order and payment workflows.

Description

Shopware exposes /store-api/handle-payment to initiate or retry the payment flow for an already created order. Under the normal order access model, customers should only be able to view or act on their own orders, and guest users should only be able to access guest orders after completing additional verification such as deepLinkCode, email address, and postal code. The Store API /store-api/order route follows this model: authenticated customers only see their own orders, and guest users are denied access unless guest-order authentication is performed. However, /store-api/handle-payment does not follow the same protection model. It only checks whether the supplied orderId exists and then directly forwards it into the payment processing flow. As a result, an attacker who cannot read orders through the intended protected route can still trigger the payment retry or payment initiation logic for another customer’s order as long as they know a valid foreign order ID. Although orderId is a UUID-based identifier and is not trivially guessable, it is used throughout storefront order flows such as checkout finish, account order pages, payment change flows, and download links. It is therefore a business object identifier, not a secret bearer token. The server must not treat knowledge of a valid orderId as sufficient authorization and must instead verify that the caller is entitled to act on the referenced order. This is a backend authorization flaw caused by missing ownership validation on a sensitive order action.

Expected Behavior

/store-api/handle-payment should only be available when the caller is the legitimate owner of the referenced order or, in the case of a guest order, when the required guest-order authentication has been completed. Before processing a supplied orderId, the server should verify that the current SalesChannelContext belongs to the customer associated with that order, or that the caller has successfully passed the expected guest-order verification flow. At a minimum, it should follow the same object-level authorization model used by the protected /store-api/order route.

Root Cause

The vulnerable endpoint accepts orderId, checks only that the order exists and has a currency, and then forwards it into the payment processor without any ownership validation.

#[Route(path: '/store-api/handle-payment', name: 'store-api.payment.handle', methods: ['GET', 'POST'])]
public function load(Request $request, SalesChannelContext $context): HandlePaymentMethodRouteResponse
{
    $data = [...$request->query->all(), ...$request->request->all()];
    $this->dataValidator->validate($data, $this->createDataValidation());
    /** @var array{orderId: string, finishUrl?: string, errorUrl?: string} $data */
    $orderCurrencyId = $this->getCurrencyFromOrder($data['orderId'], $context->getContext());

    if ($context->getCurrencyId() !== $orderCurrencyId) {
        $context = $this->contextService->get(
            new SalesChannelContextServiceParameters(
                $context->getSalesChannelId(),
                $context->getToken(),
                $context->getLanguageId(),
                $orderCurrencyId,
            )
        );
    }

    $response = $this->paymentProcessor->pay(
        $data['orderId'],
        $request,
        $context,
        $data['finishUrl'] ?? null,
        $data['errorUrl'] ?? null,
    );

    return new HandlePaymentMethodRouteResponse($response);
}

File: src/Core/Checkout/Payment/SalesChannel/HandlePaymentMethodRoute.php

The internal payment processing path similarly uses the supplied orderId to find the current transaction without checking whether the current caller owns the order.

public function pay(
    string $orderId,
    Request $request,
    SalesChannelContext $salesChannelContext,
    ?string $finishUrl = null,
    ?string $errorUrl = null,
): ?RedirectResponse {
    $transaction = $this->getCurrentOrderTransaction($orderId, $salesChannelContext->getContext());
    if (!$transaction) {
        return null;
    }

    $response = $paymentHandler->pay($request, $transactionStruct, $salesChannelContext->getContext(), $validationStruct);

    return $response;
}

private function getCurrentOrderTransaction(string $orderId, Context $context): ?OrderTransactionEntity
{
    $criteria = (new Criteria())
        ->addFilter(new EqualsFilter('stateId', $this->initialStateIdLoader->get(OrderTransactionStates::STATE_MACHINE)))
        ->addFilter(new EqualsFilter('orderId', $orderId))
        ->addSorting(new FieldSorting('createdAt', FieldSorting::DESCENDING))
        ->setLimit(1);

    $transaction = $this->orderTransactionRepository->search($criteria, $context)->getEntities()->first();

    if (!$transaction) {
        $criteria->resetFilters();
        $criteria->addFilter(new EqualsFilter('orderId', $orderId));

        if ($this->orderTransactionRepository->searchIds($criteria, $context)->firstId()) {
            return null;
        }

        throw PaymentException::invalidOrder($orderId);
    }

    return $transaction;
}

File: src/Core/Checkout/Payment/PaymentProcessor.php

By contrast, the official order retrieval route explicitly enforces current-context order ownership.

if ($context->getCustomer()) {
    $criteria->addFilter(new EqualsFilter('order.orderCustomer.customerId', $context->getCustomerId()));
} elseif ($deepLinkFilter === null) {
    throw OrderException::customerNotLoggedIn();
}

if ($deepLinkFilter !== null && !$context->getCustomer()) {
    $order = $orders->first();

    if ($order === null) {
        throw OrderException::guestNotAuthenticated();
    }

    $this->guestAuthenticator->validate($order, $request);
}

File: src/Core/Checkout/Order/SalesChannel/OrderRoute.php

The Store API schema also reflects that /store-api/order is designed for customer-owned or guest-authenticated order access, while /store-api/handle-payment only requires orderId.

{
  "summary": "Fetch a list of orders",
  "description": "List orders of a customer."
}

File: src/Core/Framework/Api/ApiDefinition/Generator/Schema/StoreApi/paths/order.json

{
  "summary": "Initiate a payment for an order",
  "required": ["orderId"]
}

File: src/Core/Framework/Api/ApiDefinition/Generator/Schema/StoreApi/paths/handle-payment.json

The expected model is that both order access and payment initiation are tied to order ownership or guest-order authentication. The implemented model instead trusts a caller-supplied orderId and allows a sensitive payment action on a foreign order.

Impact

The attacker only needs to be a normal remote Store API user and does not need to be an authenticated backend user. Even a guest context is sufficient. No administrator privileges, backend access, shell access, or other special internal conditions are required. In a realistic scenario, an external user can create a normal guest Store API context through the storefront or Store API and then submit a valid foreign order ID learned through another channel to /store-api/handle-payment in order to trigger the payment retry or payment initiation flow for another customer’s order. Here, orderId should not be treated as a secret authorization token. While it is not trivially guessable, it is used throughout storefront order-related flows such as checkout finish, account order detail pages, payment update routes, and download links as a business object identifier. Treating possession of a valid orderId as sufficient authorization breaks the expectation that only the legitimate order owner, or a properly authenticated guest-order user, may perform payment-related follow-up actions. In practice, this can lead to unauthorized payment attempts, external payment integration calls, customer confusion, and disruption of order processing integrity. The primary impact is on the integrity of order and payment workflows, with potential secondary operational or availability impact depending on the payment integration.

Patch Recommendation

Before processing a supplied orderId, /store-api/handle-payment should enforce the same object-level authorization model used by the order access routes. For authenticated customers, the server should verify that the order belongs to the current customer. For guest orders, it should require and validate the same guest-order authentication conditions used in the official order retrieval flow. In addition, the internal payment processor should not resolve a transaction solely by orderId; transaction lookup should be constrained to orders that are authorized for the current sales channel context and caller.

Summary

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 fulfillment/settlement/support process disruption.

Description

Shopware’s permission model requires server-side enforcement independent of UI guards. However, the dedicated order-state transition action endpoints are missing ACL metadata, so accounts without regular order update privileges can still submit transition requests that are processed by the backend. In real reproduction, the same low-privileged account receives 403 on the normal order update API, while the transition action API succeeds with 200 and updates order state in the database. The key point is that reproduction is possible through direct API calls regardless of UI access restrictions or hidden buttons. This is not a functional edge case; it is an implementation gap in authorization boundaries that enables privilege escalation behavior where a “read/limited-edit” user can control order lifecycle states.

Expected Behavior

• Order, order-transaction, and order-delivery transition endpoints must perform explicit server-side ACL checks.
• Requests should be rejected unless the caller has the proper entity update privileges, such as order:update, order_transaction:update, or order_delivery:update.
• If an account gets 403 on the normal order update API, transition actions on the same protected resource should also be blocked by equivalent policy.
• Even if transition internals use SYSTEM_SCOPE, caller authorization must be validated before entering the transition execution path.

Root Cause

File: src/Core/Checkout/Order/Api/OrderActionController.php

#[Route(
    path: '/api/_action/order/{orderId}/state/{transition}',
    name: 'api.action.order.state_machine.order.transition_state',
    methods: [Request::METHOD_POST]
)]
public function orderStateTransition(
    string $orderId,
    string $transition,
    Request $request,
    Context $context
): JsonResponse {
    $toPlace = $this->orderService->orderStateTransition(
        $orderId,
        $transition,
        $request->request,
        $context
    );

    return new JsonResponse($toPlace->jsonSerialize());
}

This route exposes state transitions but forwards user-controlled inputs (orderId, transition) into the service layer without PlatformRequest::ATTRIBUTE_ACL and without an explicit context->isAllowed(...) privilege check. An untrusted caller can directly control the transition target.

File: src/Core/Framework/Api/Acl/AclAnnotationValidator.php

$privileges = $request->attributes->get(PlatformRequest::ATTRIBUTE_ACL);

if (!$privileges) {
    return;
}

If route ACL metadata is absent, ACL validation exits immediately. Therefore these action routes skip authorization validation entirely.

File: src/Core/System/StateMachine/StateMachineRegistry.php

public function transition(Transition $transition, Context $context): StateMachineStateCollection
{
    return $context->scope(Context::SYSTEM_SCOPE, function (Context $context) use ($transition): StateMachineStateCollection {
        // ...
        $this->stateMachineHistoryRepository->create([$stateMachineHistoryEntity], $context);
        $repository->upsert($data, $context);
        // ...
    });
}

Transitions run in SYSTEM_SCOPE and persist state/history with system context. This requires strict pre-authorization at the route/controller boundary, but that pre-check is missing, so low-privileged calls still lead to real state changes.

Impact

The precondition is a remotely reachable authenticated low-privileged Admin API user (for example, operator/support account, or a compromised restricted account). The attacker only needs a valid order identifier, then calls transition action endpoints to cancel/reopen/advance order states without intended update privileges. This attack remains feasible even when UI access is restricted, because direct API calls still work. As a result, business workflows can be manipulated: order lifecycle integrity is broken, payment/shipping/document/notification/automation flows can be triggered incorrectly, and operational disruption can follow. In realistic scenarios, an attacker with a restricted account can mass-cancel or selectively alter orders, causing customer-support spikes, settlement inconsistencies, fulfillment mistakes, and practical availability degradation of day-to-day operations.

Patch Recommendation

• Add explicit ACL requirements to order/order-transaction/order-delivery transition routes in OrderActionController, aligned with entity update privileges.
• Centralize server-side privilege checks at transition entry points so transition paths and normal update paths follow consistent authorization policy.
• Keep SYSTEM_SCOPE writes strictly behind authorization gates; ensure caller privilege decisions are completed in pre-check logic before transition execution.
• Review transition-related APIs to guarantee privilege model mapping (order:*, order_transaction:*, order_delivery:*) is consistently enforced and no unprotected route remains.