GHSA-9RH9-HF3W-9FGG

Vulnerability from github – Published: 2026-05-18 16:37 – Updated: 2026-05-18 16:37
VLAI
Summary
shopper/framework: Race condition on Discount.usage_limit allows silent over-redemption
Details

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
Severity
5.9 (Medium)
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "shopper/cart"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.8.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-362"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-18T16:37:20Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "## Impact\n\n`CreateOrderFromCartAction::execute` previously created the `Order` row before checking and incrementing the discount\u0027s `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.\n\nA 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`.\n\nDirect financial loss: each over-redemption is a discount the merchant did not intend to grant.\n\n## Patches\n\nFixed in `v2.8.0`. `CreateOrderFromCartAction` now:\n\n- 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`.\n- Throws `DiscountLimitReachedException::global` and rolls back the transaction when the global limit was exhausted between cart validation and commit. No order is committed.\n- Throws `DiscountLimitReachedException::perUser` and rolls back when the discount is restricted to one use per customer and the customer has already redeemed it.\n- 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.\n\n`DiscountValidator` was updated to perform the same Order-based per-user check at cart-apply time so the rejection is surfaced before checkout.\n\nUpgrade via:\n\n`composer require shopper/cart:^2.8 shopper/core:^2.8`\n`php artisan migrate`\n\n## Workarounds\n\nNone. Upgrade to `v2.8.0`.\n\n## Resources\n\n- Issue: https://github.com/shopperlabs/shopper/issues/510\n- Pull request: https://github.com/shopperlabs/shopper/pull/511\n- CWE-362 Concurrent Execution using Shared Resource with Improper Synchronization",
  "id": "GHSA-9rh9-hf3w-9fgg",
  "modified": "2026-05-18T16:37:21Z",
  "published": "2026-05-18T16:37:20Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/shopperlabs/shopper/security/advisories/GHSA-9rh9-hf3w-9fgg"
    },
    {
      "type": "WEB",
      "url": "https://github.com/shopperlabs/shopper/issues/510"
    },
    {
      "type": "WEB",
      "url": "https://github.com/shopperlabs/shopper/pull/511"
    },
    {
      "type": "WEB",
      "url": "https://github.com/shopperlabs/shopper/commit/fcd0c5920588702df5b874f432b1042abd77a50b"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/shopperlabs/shopper"
    },
    {
      "type": "WEB",
      "url": "https://github.com/shopperlabs/shopper/releases/tag/v2.8.0"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "shopper/framework: Race condition on Discount.usage_limit allows silent over-redemption"
}


Log in or create an account to share your comment.




Tags
Taxonomy of the tags.





Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.

Sightings

Author Source Type Date Other

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or observed by the user.
  • Confirmed: The vulnerability has been validated from an analyst's perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
  • Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
  • Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
  • Not confirmed: The user expressed doubt about the validity of the vulnerability.
  • Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.


Detection rules are retrieved from Rulezet.