CVE-2026-48016

Shopware is an open commerce platform. Prior to 6.6.10.18 and 6.7.10.1, the Store API endpoint /store-api/handle-payment in src/Core/Checkout/Payment/SalesChannel/HandlePaymentMethodRoute.php accepts a user-controlled orderId and forwards it to src/Core/Checkout/Payment/PaymentProcessor.php without verifying order ownership or guest-order authentication, allowing a normal customer or guest context to trigger the payment flow for another user's order while /store-api/order enforces the expected ownership model. This issue is fixed in versions 6.6.10.18 and 6.7.10.1.

Shopware is an open commerce platform. Prior to 6.6.10.18 and 6.7.10.1, the Store API endpoint /store-api/handle-payment in src/Core/Checkout/Payment/SalesChannel/HandlePaymentMethodRoute.php accepts a user-controlled orderId and forwards it to src/Core/Checkout/Payment/PaymentProcessor.php without verifying order ownership or guest-order authentication, allowing a normal customer or guest context to trigger the payment flow for another user's order while /store-api/order enforces the expected ownership model. This issue is fixed in versions 6.6.10.18 and 6.7.10.1.

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,
            )
        );
    }

   …

Shopware is an open commerce platform. Prior to 6.6.10.18 and 6.7.10.1, the Store API endpoint /store-api/handle-payment in src/Core/Checkout/Payment/SalesChannel/HandlePaymentMethodRoute.php accepts a user-controlled orderId and forwards it to src/Core/Checkout/Payment/PaymentProcessor.php without verifying order ownership or guest-order authentication, allowing a normal customer or guest context to trigger the payment flow for another user's order while /store-api/order enforces the expected ownership model. This issue is fixed in versions 6.6.10.18 and 6.7.10.1.

Shopware is an open commerce platform. Prior to 6.6.10.18 and 6.7.10.1, the Store API endpoint /store-api/handle-payment in src/Core/Checkout/Payment/SalesChannel/HandlePaymentMethodRoute.php accepts a user-controlled orderId and forwards it to src/Core/Checkout/Payment/PaymentProcessor.php without verifying order ownership or guest-order authentication, allowing a normal customer or guest context to trigger the payment flow for another user's order while /store-api/order enforces the expected ownership model. This issue is fixed in versions 6.6.10.18 and 6.7.10.1.

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,
            )
        );
    }

   …