shopper/framework: Race condition on Discount.usage_limit allows silent over-redemption

Description

Impact

CreateOrderFromCartAction::execute previously created the Order row before checking and incrementing the discount's total_use counter. Under concurrent checkout pressure (Black Friday, flash sale, viral coupon), the global usage_limit was silently exceeded: orders were committed with the discount fully applied to price_amount while the counter blocked at usage_limit. The merchant had no signal that an over-redemption had occurred.

A second related bug: usage_limit_per_user was effectively a no-op because the counter it relied on (DiscountDetail.total_use) was never incremented anywhere in the codebase. The per-user check therefore always saw 0 uses and validation passed regardless of how many times the same customer had previously redeemed the coupon. For eligibility = Everyone the per-user limit could not fire at all because the underlying DiscountDetail row only exists for eligibility = Customers.

Direct financial loss: each over-redemption is a discount the merchant did not intend to grant.

Patches

Fixed in v2.8.0. CreateOrderFromCartAction now:

  • Reserves the discount slot atomically before the order row is created, inside the same DB::transaction with lockForUpdate and a compare-and-swap on total_use.
  • Throws DiscountLimitReachedException::global and rolls back the transaction when the global limit was exhausted between cart validation and commit. No order is committed.
  • Throws DiscountLimitReachedException::perUser and rolls back when the discount is restricted to one use per customer and the customer has already redeemed it.
  • Snapshots discount_id, discount_code, discount_type, discount_value_at_apply and discount_currency_code onto the orders table for resilience against later discount edits or deletions.

DiscountValidator was updated to perform the same Order-based per-user check at cart-apply time so the rejection is surfaced before checkout.

Upgrade via:

composer require shopper/cart:^2.8 shopper/core:^2.8
php artisan migrate

Workarounds

None. Upgrade to v2.8.0.

Resources

  • Issue: https://github.com/shopperlabs/shopper/issues/510
  • Pull request: https://github.com/shopperlabs/shopper/pull/511
  • CWE-362 Concurrent Execution using Shared Resource with Improper Synchronization

Basic information

Type
reviewed
Severity
medium
Advisory on GitHub
Open advisory ↗
Repository advisory
Open repository advisory ↗
Source code
Browse source ↗
Published (advisory)
2026-05-18 16:37:20 UTC
Updated
2026-06-08 20:07:27 UTC
GitHub reviewed
2026-05-18 16:37:20 UTC
NVD published
2026-05-29

EPSS Score

Score Percentile
0.03% 9.89%

CVSS Scores

Base score Version Severity Vector
5.9 3.1
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N Click to expand
Attack vector (AV:N)
Could be attacked over the internet or any normal routed network—not just someone sitting at the machine.
Attack complexity (AC:H)
Even with access, the exploit needs extra luck, timing, or a fussy environment to actually work.
Privileges required (PR:N)
No account or special rights needed—anonymous or random user is enough.
User interaction (UI:N)
Nobody has to click “OK” or open a trap file; it can work without a victim helping.
Scope (S:U)
Damage stays in the same “trust bubble” as the broken component—no big spill into unrelated systems.
Confidentiality (C:N)
Doesn’t really leak secrets in a meaningful way.
Integrity (I:H)
They could widely tamper with or forge data—trust in the data is badly hurt.
Availability (A:N)
Service keeps running; no real outage angle.

Identifiers

CWEs

CWE id Name
CWE-362 Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition')

Credits

  • baradika (reporter)

Affected packages (1)

Vulnerable version ranges and first patched releases as published by GitHub.

Ecosystem Package Vulnerable range First patched Vulnerable functions
composer shopper/cart < 2.8.0 2.8.0

References

cvelogic Threat Intelligence