
Loading

Loading
We use strictly necessary cookies to run this site, and analytics cookies to understand how it's used. See our Privacy Policy for details.
A GitHub-reviewed security advisory, not necessarily under active exploitation the way our CISA KEV advisories are, but a real, disclosed vulnerability in an open-source dependency.
Affected packages
Vulnerable: < 2.9.0
Patched in 2.9.0
Details
The Shopper Framework discount management functionality accepts negative discount values without server-side validation.
It was confirmed that negative fixed-amount discounts can be created through the administrative interface, persisted to the database, and subsequently processed by the cart/order calculation pipeline.
The application appears to assume that discount values are always positive but does not enforce this assumption during creation, storage, or calculation.
As a result, malformed discount records can influence financial calculations and produce unintended order totals.
Package: shopper/framework
Version Tested: 2.8.1
While reviewing the discount functionality, it was discovered that the application accepts negative discount values through the administrative interface.
Example values tested:
-50.00
-99,999,999.00
The application accepted these values without validation and stored them in the database.
Example records observed in the sh_discounts table:
1 | QCZ5Y3HESM | fixed_amount | -5000
4 | TOZKAHCB4S | fixed_amount | -9999999900
This demonstrates that negative discount values are successfully persisted.
Login as an administrator.
Navigate to:
/cpanel/discounts
Create a new discount with the following values:
Type: fixed_amount
Value: -99999999
Save the discount.
The discount is accepted by the application and displayed in the administration interface.
Example:
Code: TOZKAHCB4S
Amount: -$99,999,999.00
Inspect the database:
select * from sh_discounts;
Observed entry:
TOZKAHCB4S | fixed_amount | -9999999900
File:
vendor/shopper/cart/src/Discounts/DiscountCalculator.php
Observed code:
$fixedAmount = $discount->value;
The value is later processed without validation:
$fixedAmount = min($fixedAmount, $applicableSubtotal);
When a negative value is supplied:
min(-9999999900, 10000)
returns:
-9999999900
allowing the negative value to continue through the calculation pipeline.
The resulting adjustment values are inserted into the database:
CartLineAdjustment::query()->insert($adjustments);
No validation was identified to ensure that discount amounts are positive before calculations occur.
File:
vendor/shopper/cart/src/Pipelines/Calculate.php
Observed logic:
$context->total = max(
0,
$context->taxInclusive
? $context->subtotal - $context->discountTotal
: $context->subtotal - $context->discountTotal + $context->taxTotal
);
Because negative discount values are allowed to reach this stage, financial calculations are performed using malformed discount data.
Example:
Subtotal = 10000
DiscountTotal = -5000
Resulting calculation:
10000 - (-5000)
Result:
15000
This demonstrates that negative discount values directly affect order total calculations.
The following was confirmed:
Potential consequences include:
Because Shopper is a headless e-commerce administration framework and does not ship with a customer-facing storefront, it was not verified a customer-facing exploitation path.
However, malformed discount records currently propagate through pricing calculations without validation.
Implement server-side validation enforcing positive discount values before persistence and before entering the calculation pipeline.
Suggested validation:
value > 0
0 < value <= 100
Additionally, existing discount records should be validated before calculation to prevent malformed data from influencing pricing logic.
Shopper Framework 2.8.1
Laravel 12.61.1
PHP 8.4.16
SQLite
EPSS, exploit probability
Low0.43%
estimated chance of real-world exploitation in the next 30 days, higher than 37.8% of every CVE FIRST.org scores
Refreshed 10/30/2026, via FIRST.org's EPSS model, not CVSS, this measures likelihood of exploitation, not how severe it would be.
Talk to us about this
Find out whether this dependency (or others like it) is actually reachable in your codebase.
Get help patching, or building dependency-scanning into your pipeline going forward.
A secure code review or supply chain review finds this before an advisory does.