GHSA-5VF4-452P-JJHF
Vulnerability from github – Published: 2026-09-11 21:28 – Updated: 2026-09-11 21:28Summary
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.
Affected Product
Package: shopper/framework
Version Tested: 2.8.1
Vulnerability Type
- Business Logic Vulnerability
- Improper Input Validation (CWE-20)
Description
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.
Steps to Reproduce
1. Create a Discount
Login as an administrator.
Navigate to:
/cpanel/discounts
Create a new discount with the following values:
Type: fixed_amount
Value: -99999999
Save the discount.
2. Observe Successful Creation
The discount is accepted by the application and displayed in the administration interface.
Example:
Code: TOZKAHCB4S
Amount: -$99,999,999.00
3. Verify Database Persistence
Inspect the database:
select * from sh_discounts;
Observed entry:
TOZKAHCB4S | fixed_amount | -9999999900
Technical Analysis
Discount Calculation
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.
Final Total Calculation
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.
Impact
The following was confirmed:
- Negative discount values are accepted.
- Negative discount values are persisted.
- Negative discount values are processed by the discount calculation engine.
- Negative discount values affect order total calculations.
Potential consequences include:
- Incorrect pricing calculations.
- Financial data integrity issues.
- Unexpected order totals.
- Violated assumptions within downstream pricing logic.
- Future vulnerabilities if additional components assume discount values are always positive.
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.
Recommendation
Implement server-side validation enforcing positive discount values before persistence and before entering the calculation pipeline.
Suggested validation:
Fixed Amount Discounts
value > 0
Percentage Discounts
0 < value <= 100
Additionally, existing discount records should be validated before calculation to prevent malformed data from influencing pricing logic.
Environment
Shopper Framework 2.8.1
Laravel 12.61.1
PHP 8.4.16
SQLite
{
"affected": [
{
"package": {
"ecosystem": "Packagist",
"name": "shopper/framework"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2.9.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-56831"
],
"database_specific": {
"cwe_ids": [
"CWE-20"
],
"github_reviewed": true,
"github_reviewed_at": "2026-09-11T21:28:00Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "## Summary\n\nThe Shopper Framework discount management functionality accepts negative discount values without server-side validation.\n\nIt 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.\n\nThe application appears to assume that discount values are always positive but does not enforce this assumption during creation, storage, or calculation.\n\nAs a result, malformed discount records can influence financial calculations and produce unintended order totals.\n\n---\n\n## Affected Product\n\n**Package:** shopper/framework\n\n**Version Tested:** 2.8.1\n\n---\n\n## Vulnerability Type\n\n* Business Logic Vulnerability\n* Improper Input Validation (CWE-20)\n\n---\n\n## Description\n\nWhile reviewing the discount functionality, it was discovered that the application accepts negative discount values through the administrative interface.\n\nExample values tested:\n\n```text\n-50.00\n-99,999,999.00\n```\n\nThe application accepted these values without validation and stored them in the database.\n\nExample records observed in the `sh_discounts` table:\n\n```text\n1 | QCZ5Y3HESM | fixed_amount | -5000\n4 | TOZKAHCB4S | fixed_amount | -9999999900\n```\n\nThis demonstrates that negative discount values are successfully persisted.\n\n---\n\n## Steps to Reproduce\n\n### 1. Create a Discount\n\nLogin as an administrator.\n\nNavigate to:\n\n```text\n/cpanel/discounts\n```\n\nCreate a new discount with the following values:\n\n```text\nType: fixed_amount\nValue: -99999999\n```\n\nSave the discount.\n\n### 2. Observe Successful Creation\n\nThe discount is accepted by the application and displayed in the administration interface.\n\nExample:\n\n```text\nCode: TOZKAHCB4S\nAmount: -$99,999,999.00\n```\n\n### 3. Verify Database Persistence\n\nInspect the database:\n\n```sql\nselect * from sh_discounts;\n```\n\nObserved entry:\n\n```text\nTOZKAHCB4S | fixed_amount | -9999999900\n```\n\n---\n\n## Technical Analysis\n\n### Discount Calculation\n\nFile:\n\n```text\nvendor/shopper/cart/src/Discounts/DiscountCalculator.php\n```\n\nObserved code:\n\n```php\n$fixedAmount = $discount-\u003evalue;\n```\n\nThe value is later processed without validation:\n\n```php\n$fixedAmount = min($fixedAmount, $applicableSubtotal);\n```\n\nWhen a negative value is supplied:\n\n```php\nmin(-9999999900, 10000)\n```\n\nreturns:\n\n```php\n-9999999900\n```\n\nallowing the negative value to continue through the calculation pipeline.\n\nThe resulting adjustment values are inserted into the database:\n\n```php\nCartLineAdjustment::query()-\u003einsert($adjustments);\n```\n\nNo validation was identified to ensure that discount amounts are positive before calculations occur.\n\n---\n\n### Final Total Calculation\n\nFile:\n\n```text\nvendor/shopper/cart/src/Pipelines/Calculate.php\n```\n\nObserved logic:\n\n```php\n$context-\u003etotal = max(\n 0,\n $context-\u003etaxInclusive\n ? $context-\u003esubtotal - $context-\u003ediscountTotal\n : $context-\u003esubtotal - $context-\u003ediscountTotal + $context-\u003etaxTotal\n);\n```\n\nBecause negative discount values are allowed to reach this stage, financial calculations are performed using malformed discount data.\n\nExample:\n\n```text\nSubtotal = 10000\nDiscountTotal = -5000\n```\n\nResulting calculation:\n\n```text\n10000 - (-5000)\n```\n\nResult:\n\n```text\n15000\n```\n\nThis demonstrates that negative discount values directly affect order total calculations.\n\n---\n\n## Impact\n\nThe following was confirmed:\n\n* Negative discount values are accepted.\n* Negative discount values are persisted.\n* Negative discount values are processed by the discount calculation engine.\n* Negative discount values affect order total calculations.\n\nPotential consequences include:\n\n* Incorrect pricing calculations.\n* Financial data integrity issues.\n* Unexpected order totals.\n* Violated assumptions within downstream pricing logic.\n* Future vulnerabilities if additional components assume discount values are always positive.\n\nBecause 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.\n\nHowever, malformed discount records currently propagate through pricing calculations without validation.\n\n---\n\n## Recommendation\n\nImplement server-side validation enforcing positive discount values before persistence and before entering the calculation pipeline.\n\nSuggested validation:\n\n### Fixed Amount Discounts\n\n```text\nvalue \u003e 0\n```\n\n### Percentage Discounts\n\n```text\n0 \u003c value \u003c= 100\n```\n\nAdditionally, existing discount records should be validated before calculation to prevent malformed data from influencing pricing logic.\n\n---\n\n## Environment\n\n```text\nShopper Framework 2.8.1\nLaravel 12.61.1\nPHP 8.4.16\nSQLite\n```",
"id": "GHSA-5vf4-452p-jjhf",
"modified": "2026-09-11T21:28:00Z",
"published": "2026-09-11T21:28:00Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/shopperlabs/shopper/security/advisories/GHSA-5vf4-452p-jjhf"
},
{
"type": "PACKAGE",
"url": "https://github.com/shopperlabs/shopper"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:N",
"type": "CVSS_V3"
}
],
"summary": "Shopper: Negative discount values accepted and propagated through order calculation pipeline"
}
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.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.
Related by attack behaviour
Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.