CVE-2026-53639

Sylius is an Open Source eCommerce Framework on Symfony. Starting in version 2.0.0 and prior to version 2.0.18, 2.1.15, and 2.2.6, the GET /api/v2/shop/payment-requests/{hash} and PUT /api/v2/shop/payment-requests/{hash} endpoints look up the payment request solely by the hash from the URL. No ownership check is performed against the authenticated customer or the underlying order. An attacker who obtains a payment request hash can read the payment request and, through the payment IRI in the response, recover the underlying order's tokenValue (which itself grants access to the full order, items, addresses, customer email, totals); and/or update the payment request payload (e.g. target_path, after_path). These fields are used by the front-end controller to redirect the user after the payment, so an attacker can flip them to an attacker-controlled URL and intercept the buyer. The hash is a UUID, so it has to be obtained out-of-band (logs, shared links, referrer headers, a co-located client), but once it is known no other credential is required, neither authentication nor knowledge of the order token. The creation endpoint POST /api/v2/shop/orders/{tokenValue}/payment-requests shares the same flaw: it resolves the target order solely from the tokenValue in the URL without verifying that the caller owns the order. The issue is fixed in versions 2.0.18, 2.1.15, and 2.2.6. As a workaround, add a query extension that filters the GET operation; decorate the PUT state provider, guard the POST creation endpoint with a command-bus middleware, and wire the services.

Sylius is an Open Source eCommerce Framework on Symfony. Starting in version 2.0.0 and prior to version 2.0.18, 2.1.15, and 2.2.6, the GET /api/v2/shop/payment-requests/{hash} and PUT /api/v2/shop/payment-requests/{hash} endpoints look up the payment request solely by the hash from the URL. No ownership check is performed against the authenticated customer or the underlying order. An attacker who obtains a payment request hash can read the payment request and, through the payment IRI in the response, recover the underlying order's tokenValue (which itself grants access to the full order, items, addresses, customer email, totals); and/or update the payment request payload (e.g. target_path, after_path). These fields are used by the front-end controller to redirect the user after the payment, so an attacker can flip them to an attacker-controlled URL and intercept the buyer. The hash is a UUID, so it has to be obtained out-of-band (logs, shared links, referrer headers, a co-located client), but once it is known no other credential is required, neither authentication nor knowledge of the order token. The creation endpoint POST /api/v2/shop/orders/{tokenValue}/payment-requests shares the same flaw: it resolves the target order solely from the tokenValue in the URL without verifying that the caller owns the order. The issue is fixed in versions 2.0.18, 2.1.15, and 2.2.6. As a workaround, add a query extension that filters the GET operation; decorate the PUT state provider, guard the POST creation endpoint with a command-bus middleware, and wire the services.

Impact

The GET /api/v2/shop/payment-requests/{hash} and PUT /api/v2/shop/payment-requests/{hash} endpoints look up the payment request solely by the hash from the URL. No ownership check is performed against the authenticated customer or the underlying order.

An attacker who obtains a payment request hash can:

• read the payment request and, through the payment IRI in the response, recover the underlying order's tokenValue (which itself grants access to the full order, items, addresses, customer email, totals);
• update the payment request payload (e.g. target_path, after_path). These fields are used by the front-end controller to redirect the user after the payment, so an attacker can flip them to an attacker-controlled URL and intercept the buyer.

The hash is a UUID, so it has to be obtained out-of-band (logs, shared links, referrer headers, a co-located client), but once it is known no other credential is required, neither authentication nor knowledge of the order token.

The creation endpoint POST /api/v2/shop/orders/{tokenValue}/payment-requests shares the same flaw: it resolves the target order solely from the tokenValue in the URL without verifying that the caller owns the order.

Patches

The issue is fixed in versions: 2.0.18, 2.1.15, 2.2.6.

Workarounds

Until you can upgrade, apply the following workaround. It enforces ownership on the existing endpoints, so that:

• an authenticated shop user may only access payment requests of their own orders;
• an anonymous caller may only access payment requests of guest orders (the order's customer has no associated user account);
• everyone else receives 404 Not Found.

Step 1. Add a query extension that filters the GET operation

Create file src/ApiPlatform/QueryExtension/PaymentRequestOwnershipExtension.php:

<?php

declare(strict_types=1);

namespace App\ApiPlatform\QueryExtension;

use ApiPlatform\Doctrine\Orm\Extension\QueryItemExtensionInterface;
use ApiPlatform\Doctrine\Orm\Util\QueryNameGeneratorInterface;
use ApiPlatform\Metadata\Operation;
use Doctrine\ORM\QueryBuilder;
use Sylius\Bundle\ApiBundle\Context\UserContextInterface;
use Sylius\Bundle\ApiBundle\SectionResolver\ShopApiSection;
use Sylius\Bundle\CoreBundle\SectionResolver\SectionProviderInterface;
use Sylius\Component\Core\Model\ShopUserInterface;
use Sylius\Component\Payment\Model\PaymentRequestInterface;

final readonly class PaymentRequestOwnershipExtension implements QueryItemExtensionInterface
{
    public function __construct(
        private SectionProviderInterface $sectionProvider,
        private UserContextInterface $userContext,
    ) {
    }

    public function applyToItem(
        QueryBuilder $queryBuilder,
        QueryNameGeneratorInterface $queryNameGenerator,
        string $resourceClass,
        array $identifiers,
        ?Operation $operation = null,
        array $context = [],
    ): void {
        if (!is_a($resourceClass, PaymentRequestInterface::class, true)) {
            return;
        }

        if (!$this->sectionProvider->getSection() instanceof ShopApiSection) {
            return;
        }

        $rootAlias = $queryBuilder->getRootAliases()[0];
        $paymentJoin = $queryNameGenerator->generateJoinAlias('payment');
        $orderJoin = $queryNameGenerator->generateJoinAlias('order');
        $customerJoin = $queryNameGenerator->generateJoinAlias('customer');
        $userJoin = $queryNameGenerator->generateJoinAlias('user');
        $createdByGuestParameterName = $queryNameGenerator->generateParameterName('createdByGuest');

        $queryBuilder
            ->innerJoin(sprintf('%s.payment', $rootAlias), $paymentJoin)
            ->innerJoin(sprintf('%s.order', $paymentJoin), $orderJoin)
            ->leftJoin(sprintf('%s.customer', $orderJoin), $customerJoin)
            ->leftJoin(sprintf('%s.user', $customerJoin), $userJoin)
        ;

        $user = $this->userContext->getUser();

        if ($user instanceof…

Sylius is an Open Source eCommerce Framework on Symfony. Starting in version 2.0.0 and prior to version 2.0.18, 2.1.15, and 2.2.6, the GET /api/v2/shop/payment-requests/{hash} and PUT /api/v2/shop/payment-requests/{hash} endpoints look up the payment request solely by the hash from the URL. No ownership check is performed against the authenticated customer or the underlying order. An attacker who obtains a payment request hash can read the payment request and, through the payment IRI in the response, recover the underlying order's tokenValue (which itself grants access to the full order, items, addresses, customer email, totals); and/or update the payment request payload (e.g. target_path, after_path). These fields are used by the front-end controller to redirect the user after the payment, so an attacker can flip them to an attacker-controlled URL and intercept the buyer. The hash is a UUID, so it has to be obtained out-of-band (logs, shared links, referrer headers, a co-located client), but once it is known no other credential is required, neither authentication nor knowledge of the order token. The creation endpoint POST /api/v2/shop/orders/{tokenValue}/payment-requests shares the same flaw: it resolves the target order solely from the tokenValue in the URL without verifying that the caller owns the order. The issue is fixed in versions 2.0.18, 2.1.15, and 2.2.6. As a workaround, add a query extension that filters the GET operation; decorate the PUT state provider, guard the POST creation endpoint with a command-bus middleware, and wire the services.

Sylius is an Open Source eCommerce Framework on Symfony. Starting in version 2.0.0 and prior to version 2.0.18, 2.1.15, and 2.2.6, the GET /api/v2/shop/payment-requests/{hash} and PUT /api/v2/shop/payment-requests/{hash} endpoints look up the payment request solely by the hash from the URL. No ownership check is performed against the authenticated customer or the underlying order. An attacker who obtains a payment request hash can read the payment request and, through the payment IRI in the response, recover the underlying order's tokenValue (which itself grants access to the full order, items, addresses, customer email, totals); and/or update the payment request payload (e.g. target_path, after_path). These fields are used by the front-end controller to redirect the user after the payment, so an attacker can flip them to an attacker-controlled URL and intercept the buyer. The hash is a UUID, so it has to be obtained out-of-band (logs, shared links, referrer headers, a co-located client), but once it is known no other credential is required, neither authentication nor knowledge of the order token. The creation endpoint POST /api/v2/shop/orders/{tokenValue}/payment-requests shares the same flaw: it resolves the target order solely from the tokenValue in the URL without verifying that the caller owns the order. The issue is fixed in versions 2.0.18, 2.1.15, and 2.2.6. As a workaround, add a query extension that filters the GET operation; decorate the PUT state provider, guard the POST creation endpoint with a command-bus middleware, and wire the services.

Impact

The GET /api/v2/shop/payment-requests/{hash} and PUT /api/v2/shop/payment-requests/{hash} endpoints look up the payment request solely by the hash from the URL. No ownership check is performed against the authenticated customer or the underlying order.

An attacker who obtains a payment request hash can:

• read the payment request and, through the payment IRI in the response, recover the underlying order's tokenValue (which itself grants access to the full order, items, addresses, customer email, totals);
• update the payment request payload (e.g. target_path, after_path). These fields are used by the front-end controller to redirect the user after the payment, so an attacker can flip them to an attacker-controlled URL and intercept the buyer.

The hash is a UUID, so it has to be obtained out-of-band (logs, shared links, referrer headers, a co-located client), but once it is known no other credential is required, neither authentication nor knowledge of the order token.

The creation endpoint POST /api/v2/shop/orders/{tokenValue}/payment-requests shares the same flaw: it resolves the target order solely from the tokenValue in the URL without verifying that the caller owns the order.

Patches

The issue is fixed in versions: 2.0.18, 2.1.15, 2.2.6.

Workarounds

Until you can upgrade, apply the following workaround. It enforces ownership on the existing endpoints, so that:

• an authenticated shop user may only access payment requests of their own orders;
• an anonymous caller may only access payment requests of guest orders (the order's customer has no associated user account);
• everyone else receives 404 Not Found.

Step 1. Add a query extension that filters the GET operation

Create file src/ApiPlatform/QueryExtension/PaymentRequestOwnershipExtension.php:

<?php

declare(strict_types=1);

namespace App\ApiPlatform\QueryExtension;

use ApiPlatform\Doctrine\Orm\Extension\QueryItemExtensionInterface;
use ApiPlatform\Doctrine\Orm\Util\QueryNameGeneratorInterface;
use ApiPlatform\Metadata\Operation;
use Doctrine\ORM\QueryBuilder;
use Sylius\Bundle\ApiBundle\Context\UserContextInterface;
use Sylius\Bundle\ApiBundle\SectionResolver\ShopApiSection;
use Sylius\Bundle\CoreBundle\SectionResolver\SectionProviderInterface;
use Sylius\Component\Core\Model\ShopUserInterface;
use Sylius\Component\Payment\Model\PaymentRequestInterface;

final readonly class PaymentRequestOwnershipExtension implements QueryItemExtensionInterface
{
    public function __construct(
        private SectionProviderInterface $sectionProvider,
        private UserContextInterface $userContext,
    ) {
    }

    public function applyToItem(
        QueryBuilder $queryBuilder,
        QueryNameGeneratorInterface $queryNameGenerator,
        string $resourceClass,
        array $identifiers,
        ?Operation $operation = null,
        array $context = [],
    ): void {
        if (!is_a($resourceClass, PaymentRequestInterface::class, true)) {
            return;
        }

        if (!$this->sectionProvider->getSection() instanceof ShopApiSection) {
            return;
        }

        $rootAlias = $queryBuilder->getRootAliases()[0];
        $paymentJoin = $queryNameGenerator->generateJoinAlias('payment');
        $orderJoin = $queryNameGenerator->generateJoinAlias('order');
        $customerJoin = $queryNameGenerator->generateJoinAlias('customer');
        $userJoin = $queryNameGenerator->generateJoinAlias('user');
        $createdByGuestParameterName = $queryNameGenerator->generateParameterName('createdByGuest');

        $queryBuilder
            ->innerJoin(sprintf('%s.payment', $rootAlias), $paymentJoin)
            ->innerJoin(sprintf('%s.order', $paymentJoin), $orderJoin)
            ->leftJoin(sprintf('%s.customer', $orderJoin), $customerJoin)
            ->leftJoin(sprintf('%s.user', $customerJoin), $userJoin)
        ;

        $user = $this->userContext->getUser();

        if ($user instanceof…