<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet href="/static/style.xsl" type="text/xsl"?>
<rss xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/" version="2.0">
  <channel>
    <title>Most recent entries from all</title>
    <link>https://cve.radiocsirt.org</link>
    <description>Contains only the most 10 recent entries.</description>
    <docs>http://www.rssboard.org/rss-specification</docs>
    <generator>python-feedgen</generator>
    <language>en</language>
    <lastBuildDate>Thu, 08 Oct 2026 17:22:51 +0000</lastBuildDate>
    <item>
      <title>EUVD-2026-322959</title>
      <link>https://cve.radiocsirt.org/vuln/euvd-2026-322959</link>
      <description>EUVD-2026-322959</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/euvd-2026-322959</guid>
    </item>
    <item>
      <title>fkie_cve-2026-47741</title>
      <link>https://cve.radiocsirt.org/vuln/fkie_cve-2026-47741</link>
      <description>&lt;p&gt;Shopper is a Headless e-commerce Admin Panel. Prior to 2.8.0, CreateOrderFromCartAction::execute previously created the Order row before checking and incrementing the discount&amp;#39;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. This vulnerability is fixed in 2.8.0.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;Shopper is a Headless e-commerce Admin Panel. Prior to 2.8.0, CreateOrderFromCartAction::execute previously created the Order row before checking and incrementing the discount&amp;#39;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. This vulnerability is fixed in 2.8.0.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/fkie_cve-2026-47741</guid>
    </item>
    <item>
      <title>GHSA-9rh9-hf3w-9fgg — shopper/framework: Race condition on Discount.usage_limit allows silent over-redemption</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-9rh9-hf3w-9fgg</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Packagist: shopper/cart&lt;/p&gt;
&lt;p&gt;## Impact&lt;/p&gt;
&lt;p&gt;`CreateOrderFromCartAction::execute` previously created the `Order` row before checking and incrementing the discount&amp;#39;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.&lt;/p&gt;
&lt;p&gt;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`.&lt;/p&gt;
&lt;p&gt;Direct financial loss: each over-redemption is a discount the merchant did not intend to grant.&lt;/p&gt;
&lt;p&gt;## Patches&lt;/p&gt;
&lt;p&gt;Fixed in `v2.8.0`. `CreateOrderFromCartAction` now:&lt;/p&gt;
&lt;p&gt;- 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::perU…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Packagist: shopper/cart&lt;/p&gt;
&lt;p&gt;## Impact&lt;/p&gt;
&lt;p&gt;`CreateOrderFromCartAction::execute` previously created the `Order` row before checking and incrementing the discount&amp;#39;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.&lt;/p&gt;
&lt;p&gt;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`.&lt;/p&gt;
&lt;p&gt;Direct financial loss: each over-redemption is a discount the merchant did not intend to grant.&lt;/p&gt;
&lt;p&gt;## Patches&lt;/p&gt;
&lt;p&gt;Fixed in `v2.8.0`. `CreateOrderFromCartAction` now:&lt;/p&gt;
&lt;p&gt;- 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::perU…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-9rh9-hf3w-9fgg</guid>
    </item>
  </channel>
</rss>
