CVE-2026-100869 in Sylius
Summary
by MITRE • 09/27/2026
Sylius versions before 2.1.16 and 2.2.9 fail to restrict payment request actions in the Shop API endpoint, allowing customers to trigger refunds on completed orders. Attackers with order tokens can submit arbitrary payment actions like refunds that payment gateways execute while Sylius maintains order as paid, causing financial loss.
Be aware that VulDB is the high quality source for vulnerability data.
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 authorization flaw within the Shop API endpoint responsible for handling payment requests. This issue stems from an insufficient access control mechanism that fails to properly validate whether a user is permitted to execute specific financial actions on existing orders. Specifically, the system does not restrict customers from triggering refund operations on orders that have already been marked as completed and paid. In a secure e-commerce architecture, once an order reaches a final state such as paid or shipped, subsequent payment-related API calls should be strictly limited to read-only operations or specific post-completion actions like returns, which are typically handled through separate workflows with distinct authorization checks. The absence of these restrictions allows any authenticated user possessing the valid token for an order to manipulate its financial status arbitrarily.
From a technical perspective, this flaw is classified under CWE-269 Improper Privilege Management and aligns with MITRE ATT&CK technique T1078 Valid Accounts, as it leverages legitimate credentials to perform unauthorized actions. The core issue lies in the backend logic of the Shop API endpoint, which processes payment action requests without verifying the current state of the order against a whitelist of allowed transitions for that specific user role and order status. When an attacker submits a refund request using their valid order token, the Sylius application forwards this instruction to the configured payment gateway. The payment gateway, operating independently based on the API payload it receives, executes the financial transaction by reversing the funds back to the customer's original payment method. This creates a dangerous state of inconsistency where the external banking system reflects a refund while the internal database continues to display the order as paid and fulfilled.
The operational impact of this vulnerability is severe and directly results in tangible financial loss for merchants. Because Sylius maintains the order status as paid, it does not trigger any inventory restocking workflows, shipping cancellations, or customer service notifications that would normally accompany a legitimate refund process. Consequently, the merchant loses both the revenue from the sale and the physical goods associated with the order, assuming they have already been shipped based on the false assumption of payment confirmation. This discrepancy can also lead to significant accounting discrepancies and audit failures, as financial records will not match inventory movements or customer service logs. Furthermore, this flaw undermines trust in the platform's integrity, potentially exposing merchants to chargebacks if customers dispute charges despite having received their goods, given that the system shows no record of a refund being processed internally.
Mitigation for this vulnerability requires an immediate upgrade to Sylius version 2.1.16 or later, where these authorization checks have been implemented and validated by the development team. For organizations unable to patch immediately due to dependency constraints, temporary workarounds involve implementing custom middleware or event listeners that intercept payment action requests at the API layer. These controls should explicitly check the order status before allowing any write operations related to payments. If an order is in a final state such as paid, shipped, or closed, the system must reject refund-related actions unless they are part of a dedicated return management workflow with separate authentication and authorization scopes. Additionally, merchants should review their payment gateway configurations to ensure that refunds require additional verification steps where possible, although relying solely on gateway-side controls is not sufficient given the application-level flaw. Regular security audits focusing on API endpoint permissions and state machine transitions for order lifecycles are recommended to prevent similar privilege escalation issues in future development cycles.