CVE-2026-100872 in Sylius
Summary
by MITRE • 09/27/2026
Sylius versions before 2.1.16 and 2.2.9 fail to validate payment amounts during cart recalculation, allowing unauthenticated attackers to modify order totals after gateway transaction initiation. Attackers can pay a small amount, enlarge the order after gateway capture, and have the system mark the inflated order as fully paid while the gateway captured only the original amount.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 09/27/2026
The vulnerability identified in Sylius versions prior to 2.1.16 and 2.2.9 represents a critical flaw in the financial logic of the e-commerce platform, specifically within the cart recalculation mechanism. This issue stems from an insufficient validation of payment amounts during the process of updating order totals after a transaction has been initiated with a payment gateway. In standard secure implementations, any modification to an order's contents or total value should trigger a re-authorization or at least a strict verification against the originally authorized amount by the payment processor. However, in these affected versions, the system fails to enforce this constraint during cart recalculation, creating a significant gap between the financial state recorded by Sylius and the actual funds captured by the external payment gateway.
From a technical perspective, the flaw allows unauthenticated attackers to exploit the sequence of events surrounding order processing. An attacker can initiate an order with a legitimate small amount through the checkout process, which triggers the initial transaction request to the payment gateway. Once this gateway capture or authorization is complete and confirmed by Sylius as successful, the attacker modifies the cart contents to increase the total value of the order without re-initiating the payment flow. Because the system does not validate that the new total matches the captured amount, it accepts these changes and marks the inflated order as fully paid based on the original transaction record. This effectively decouples the internal accounting state from the external financial reality, allowing goods or services to be claimed for a fraction of their actual cost.
The operational impact of this vulnerability is severe, primarily constituting direct financial loss through fraud. Attackers can engage in what is known as an order manipulation attack, where they receive high-value items while only paying low amounts. This not only results in the immediate loss of revenue and inventory for merchants but also introduces significant reputational risk if such fraudulent activities are discovered by legitimate customers or payment processors. Furthermore, this flaw undermines the integrity of financial reporting and audit trails within the application, as the database records transactions that do not reflect actual cash flow, complicating reconciliation efforts and potentially violating compliance requirements related to accurate financial record-keeping.
This vulnerability aligns with CWE-345 Insufficient Verification of Data Authenticity, as the system fails to verify that the data (order total) remains consistent with the authenticated state established by the payment gateway. It also maps closely to MITRE ATT&CK technique T1078 Valid Accounts if leveraged through compromised credentials, though in this specific case it is exploitable by unauthenticated users via API manipulation or form tampering, fitting broader categories of business logic errors and input validation failures. The attack vector typically involves intercepting the cart update requests and modifying line items or quantities after the payment confirmation step has been processed but before final order fulfillment.
Mitigation strategies must focus on enforcing strict state consistency between the application's internal order management system and external payment gateways. Developers should implement a check during any cart recalculation that compares the new total against the amount already captured by the gateway. If an increase in value is detected, the system must either reject the modification entirely or force the user to complete a new authorization process for the difference. Upgrading to Sylius version 2.1.16 or 2.2.9 and later resolves this issue as these versions include patches that enforce proper validation of payment amounts during cart updates. Additionally, implementing server-side logic that treats any post-payment modification as requiring re-authorization is a critical defensive measure for applications handling financial transactions to prevent similar business logic vulnerabilities in the future.