CVE-2026-31824: Sylius has a Promotion Usage Limit Bypass via Race Condition

Published Mar 10, 2026
·
Updated

Impact A Time-of-Check To Time-of-Use (TOCTOU) race condition was discovered in the promotion usage limit enforcement. The same class of vulnerability affects three independent limits:

1. Promotion usage limit - the global used counter on Promotion entities 2. Coupon usage limit - the global used counter on PromotionCoupon entities 3. Coupon per-customer usage limit - the per-customer redemption count on PromotionCoupon entities

In all three cases, the eligibility check reads the used counter (or order count) from an in-memory Doctrine entity during validation, while the actual usage increment in OrderPromotionsUsageModifier happens later during order completion — with no database-level locking or atomic operations between the two phases.

Because Doctrine flushes an absolute value (SET used = 1) rather than an atomic increment (SET used = used + 1), and because the affected entities lack optimistic locking, concurrent requests all read the same stale usage counts and pass the eligibility checks simultaneously.

An attacker can exploit this by preparing multiple carts with the same limited-use promotion or coupon and firing simultaneous PATCH /api/v2/shop/orders/{token}/complete requests. All requests pass the usage limit checks and complete successfully, allowing a single-use promotion or coupon to be redeemed an arbitrary number of times. The per-customer limit can be bypassed in the same way by a single customer completing multiple orders concurrently. No authentication is required to exploit this vulnerability.

This may lead to direct financial loss through unlimited redemption of limited-use promotions and discount coupons.

Patches The issue is fixed in versions: 1.9.12, 1.10.16, 1.11.17, 1.12.23, 1.13.15, 1.14.18, 2.0.16, 2.1.12, 2.2.3 and above.

Workarounds

Decoration of the OrderPromotionsUsageModifier service to use atomic operations based on actual database-synchronized values.

The decorated service id in Sylius >=2.0 is sylius.modifier.promotion.orderusage, while <2.0 it's sylius.promotionusagemodifier; The following instruction uses the latter, but it needs to be changed depending on the Sylius version.

Step 1. Create the decorator service

src/Modifier/AtomicOrderPromotionsUsageModifier.php:

php <?php

declare(stricttypes=1);

namespace App\Modifier;

use Doctrine\DBAL\Connection; use Doctrine\ORM\OptimisticLockException; use Sylius\Component\Core\Model\OrderInterface; use Sylius\Component\Core\Model\PromotionCouponInterface; use Sylius\Component\Core\Promotion\Modifier\OrderPromotionsUsageModifierInterface; use Sylius\Component\Promotion\Model\PromotionInterface; // use Symfony\Component\DependencyInjection\Attribute\AsDecorator;

// #[AsDecorator(decorates: 'sylius.promotionusagemodifier')] final class AtomicOrderPromotionsUsageModifier implements OrderPromotionsUsageModifierInterface { / @var Connection / private $connection;

public function construct(Connection $connection) { $this->connection = $connection; }

public function increment(OrderInterface $order): void { foreach ($order->getPromotions() as $promotion) { $this->incrementPromotionUsage($promotion); }

/ @var PromotionCouponInterface|null $coupon / $coupon = $order->getPromotionCoupon(); if (null === $coupon) { return; }

$this->incrementCouponUsage($coupon, $order); }

public function decrement(OrderInterface $order): void { foreach ($order->getPromotions() as $promotion) { $this->decrementPromotionUsage($promotion); }

/ @var PromotionCouponInterface|null $coupon / $coupon = $order->getPromotionCoupon(); if (null === $coupon) { return; }

if (OrderInterface::STATECANCELLED === $order->getState() && !$coupon->isReusableFromCancelledOrders()) { return; }

$this->decrementCouponUsage($coupon); }

private function incrementPromotionUsage(PromotionInterface $promotion): void { $affected = $this->doExecuteStatement( 'UPDATE syliuspromotion SET used = used + 1 WHERE id = :id AND (usagelimit IS NULL OR used < usagelimit)', ['id' => $promotion->getId()] );

if (0 === $affected) { throw new OptimisticLockException(sprintf('Promotion "%s" is no longer applicable.', $promotion->getCode()), $promotion); }

$newUsed = (int) $this->doFetchOne( 'SELECT used FROM syliuspromotion WHERE id = :id', ['id' => $promotion->getId()] );

$promotion->setUsed($newUsed); }

private function decrementPromotionUsage(PromotionInterface $promotion): void { $this->doExecuteStatement( 'UPDATE syliuspromotion SET used = GREATEST(used - 1, 0) WHERE id = :id', ['id' => $promotion->getId()] );

$newUsed = (int) $this->doFetchOne( 'SELECT used FROM syliuspromotion WHERE id = :id', ['id' => $promotion->getId()] );

$promotion->setUsed($newUsed); }

private function incrementCouponUsage(PromotionCouponInterface $coupon, OrderInterface $order): void { $row = $this->doFetchAssociative( 'SELECT used, usagelimit, percustomerusagelimit FROM syliuspromotioncoupon WHERE id = :id FOR UPDATE', ['id' => $coupon->getId()] );

if (false === $row) { throw new OptimisticLockException(sprintf('Promotion coupon "%s" is no longer applicable.', $coupon->getCode()), $coupon); }

if (null !== $row['usagelimit'] && (int) $row['used'] >= (int) $row['usagelimit']) { throw new OptimisticLockException(sprintf('Promotion coupon "%s" is no longer applicable.', $coupon->getCode()), $coupon); }

if (null !== $row['percustomerusagelimit']) { $this->assertPerCustomerCouponUsageLimitNotReached( $coupon, $order, (int) $row['percustomerusagelimit'] ); }

$this->doExecuteStatement( 'UPDATE syliuspromotioncoupon SET used = used + 1 WHERE id = :id', ['id' => $coupon->getId()] );

$coupon->setUsed((int) $row['used'] + 1); }

private function assertPerCustomerCouponUsageLimitNotReached( PromotionCouponInterface $coupon, OrderInterface $order, int $perCustomerUsageLimit ): void { $customer = $order->getCustomer(); if (null === $customer || null === $customer->getId()) { return; }

$sql = 'SELECT o.id FROM syliusorder o WHERE o.customerid = :customerId AND o.promotioncouponid = :couponId AND o.state != :stateCart'; $params = [ 'customerId' => $customer->getId(), 'couponId' => $coupon->getId(), 'stateCart' => OrderInterface::STATECART, ];

if ($coupon->isReusableFromCancelledOrders()) { $sql .= ' AND o.state != :stateCancelled'; $params['stateCancelled'] = OrderInterface::STATECANCELLED; }

$sql .= ' FOR UPDATE';

$count = count($this->doFetchAllAssociative($sql, $params));

if ($count >= $perCustomerUsageLimit) { throw new OptimisticLockException(sprintf('Promotion coupon "%s" is no longer applicable.', $coupon->getCode()), $coupon); } }

private function decrementCouponUsage(PromotionCouponInterface $coupon): void { $this->doExecuteStatement( 'UPDATE syliuspromotioncoupon SET used = GREATEST(used - 1, 0) WHERE id = :id', ['id' => $coupon->getId()] );

$newUsed = (int) $this->doFetchOne( 'SELECT used FROM syliuspromotioncoupon WHERE id = :id', ['id' => $coupon->getId()] );

$coupon->setUsed($newUsed); }

/ @return int Number of affected rows / private function doExecuteStatement(string $sql, array $params): int { if (methodexists($this->connection, 'executeStatement')) { return $this->connection->executeStatement($sql, $params); }

return $this->connection->executeUpdate($sql, $params); }

/ @return mixed|false / private function doFetchOne(string $sql, array $params) { if (methodexists($this->connection, 'fetchOne')) { return $this->connection->fetchOne($sql, $params); }

return $this->connection->fetchColumn($sql, $params); }

/ @return array|false / private function doFetchAssociative(string $sql, array $params) { if (methodexists($this->connection, 'fetchAssociative')) { return $this->connection->fetchAssociative($sql, $params); }

return $this->connection->fetchAssoc($sql, $params); }

/ @return array[] / private function doFetchAllAssociative(string $sql, array $params): array { if (methodexists($this->connection, 'fetchAllAssociative')) { return $this->connection->fetchAllAssociative($sql, $params); }

return $this->connection->fetchAll($sql, $params); } }

Step 2. Register the service

Option A: If your app uses autowiring and supports the #[AsDecorator] attribute, uncomment it in the class and no further configuration is necessary.

Option B: Manually register the service in config/services.yaml:

yaml services: App\Modifier\AtomicOrderPromotionsUsageModifier: decorates: 'sylius.promotionusagemodifier' arguments: ['@doctrine.dbal.defaultconnection']

Step 3. Update exception mapping (optional)

Check if your apiplatform configuration maps OptimisticLockException to a code and update it if not: yaml apiplatform: ... exceptiontostatus: ... Doctrine\ORM\OptimisticLockException: 409

Step 4. Clear cache

bash bin/console cache:clear

Reporters

We would like to extend our gratitude to the following individuals for their detailed reporting and responsible disclosure of this vulnerability: - Djibril Mounkoro (@whiteov3rflow) - Bartłomiej Nowiński (@bnBart)

For more information

If you have any questions or comments about this advisory:

- Open an issue in Sylius issues - Email us at security@sylius.com

Other sources

Sylius is an Open Source eCommerce Framework on Symfony. A Time-of-Check To Time-of-Use (TOCTOU) race condition was discovered in the promotion usage limit enforcement. The same class of vulnerability affects the promotion usage limit (the global used counter on Promotion entities), coupon usage limit (the global used counter on PromotionCoupon entities), and coupon per-customer usage limit (the per-customer redemption count on PromotionCoupon entities). In all three cases, the eligibility check reads the used counter (or order count) from an in-memory Doctrine entity during validation, while the actual usage increment in OrderPromotionsUsageModifier happens later during order completion — with no database-level locking or atomic operations between the two phases. Because Doctrine flushes an absolute value (SET used = 1) rather than an atomic increment (SET used = used + 1), and because the affected entities lack optimistic locking, concurrent requests all read the same stale usage counts and pass the eligibility checks simultaneously. An attacker can exploit this by preparing multiple carts with the same limited-use promotion or coupon and firing simultaneous PATCH /api/v2/shop/orders/{token}/complete requests. All requests pass the usage limit checks and complete successfully, allowing a single-use promotion or coupon to be redeemed an arbitrary number of times. The per-customer limit can be bypassed in the same way by a single customer completing multiple orders concurrently. No authentication is required to exploit this vulnerability. This may lead to direct financial loss through unlimited redemption of limited-use promotions and discount coupons. The issue is fixed in versions: 1.9.12, 1.10.16, 1.11.17, 1.12.23, 1.13.15, 1.14.18, 2.0.16, 2.1.12, 2.2.3 and above.

— MITRE

Affected Software

19 affected componentsFixes available
pypi/sylius<1.9.12, <1.10.16, <1.11.17, <1.12.23, <1.13.15, <1.14.18, <2.0.16, <2.1.12, <2.2.3
composer/sylius/sylius>=2.2.0<=2.2.2
2.2.3
composer/sylius/sylius>=2.1.0<=2.1.11
2.1.12
composer/sylius/sylius>=2.0.0<=2.0.15
2.0.16
composer/sylius/sylius>=1.14.0<=1.14.17
1.14.18
composer/sylius/sylius>=1.13.0<=1.13.14
1.13.15
composer/sylius/sylius>=1.12.0<=1.12.22
1.12.23
composer/sylius/sylius>=1.11.0<=1.11.16
1.11.17
composer/sylius/sylius>=1.10.0<=1.10.15
1.10.16
composer/sylius/sylius<=1.9.11
1.9.12
Sylius Sylius<1.9.12
Sylius Sylius>=1.10.0<1.10.16
Sylius Sylius>=1.11.0<1.11.17
Sylius Sylius>=1.12.0<1.12.23
Sylius Sylius>=1.13.0<1.13.15
Sylius Sylius>=1.14.0<1.14.18
Sylius Sylius>=2.0.0<2.0.16
Sylius Sylius>=2.1.0<2.1.12
Sylius Sylius>=2.2.0<2.2.3

Event History

Mar 10, 2026
CVE Published
via MITRE·09:32 PM
Data Sourced
via MITRE·09:32 PM
DescriptionSeverityWeakness
Data Sourced
via NVD·10:16 PM
DescriptionSeverityWeaknessAffected Software
Mar 11, 2026
Advisory Published
via GitHub·12:13 AM
Data Sourced
via GitHub·12:13 AM
DescriptionSeverityWeaknessAffected Software
May 6, 58175
Event
via FIRST·10:11 AM

Frequently Asked Questions

1

What is the severity of CVE-2026-31824?

CVE-2026-31824 is classified as a high-severity vulnerability due to its impact on promotion usage limits in Sylius.

2

How do I fix CVE-2026-31824?

To fix CVE-2026-31824, update your Sylius installation to the latest version that contains the patch for the promotion usage limit bypass.

3

What systems are affected by CVE-2026-31824?

CVE-2026-31824 affects Sylius installations that utilize the promotion functionality and do not implement the necessary protections against the race condition.

4

Can CVE-2026-31824 be exploited remotely?

Yes, CVE-2026-31824 can be exploited remotely by an attacker to bypass promotion usage limits in vulnerable Sylius applications.

5

What is a race condition in the context of CVE-2026-31824?

In the context of CVE-2026-31824, a race condition refers to the flaw that occurs when multiple processes access shared resources simultaneously, allowing exploitation of the promotion usage limits.

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203