Security is, and always will be, our top priority. Protecting the merchants and customers who rely on Sylius every day is something we treat as a continuous responsibility. This is why we strongly recommend keeping Sylius installations up to date, especially when security releases are available. This round of fixes started with a few independent reports concerning the shop API and the cart Live Components. Rather than patching each one on its own, we reviewed the authorization and order-state handling around them more thoroughly, so that every affected operation is hardened in the same consistent way.
If your store runs a version below 2.0.18, 2.1.15 or 2.2.6, we strongly encourage you to upgrade as soon as possible. The issues described below include a broken object-level authorization (IDOR) on payment requests, an authorization bypass on the account payments endpoint, and a race condition that can corrupt or even delete an order that has already been placed, with possible data loss and financial impact for merchants.
A safe eCommerce environment depends on staying ahead of issues like these, and we are grateful for the trust and vigilance of our community. Below, we outline each issue, its impact, and the steps you should take to protect your business.
The original security advisory has been published on GitHub at Sylius/Sylius repository.
The PATCH /api/v2/shop/account/orders/{tokenValue}/payments/{paymentId} endpoint, used by an authenticated customer to change the payment method of a placed but unpaid order, does not validate that the chosen payment method is enabled for the order’s channel. The equivalent checkout endpoint correctly rejects out-of-channel payment methods with HTTP 422; the account endpoint silently accepts them and returns HTTP 200. An authenticated customer can therefore assign any globally enabled payment method to their own order, including methods the store operator has explicitly excluded from that channel.
The issue is fixed in versions: 2.0.18, 2.1.15, 2.2.6 and above.
If an immediate upgrade is not possible, decorate the PaymentMethodChangerInterface service to re-validate the chosen payment method against the channel’s supported methods. See the full workaround in the advisory.
The original security advisory has been published on GitHub at Sylius/Sylius repository.
The PATCH /api/v2/shop/account/orders/{tokenValue}/payments/{paymentId} endpoint, used by an authenticated customer to change the payment method of a placed but unpaid order, does not validate that the chosen payment method is enabled for the order’s channel. The equivalent checkout endpoint correctly rejects out-of-channel payment methods with HTTP 422; the account endpoint silently accepts them and returns HTTP 200. An authenticated customer can therefore assign any globally enabled payment method to their own order, including methods the store operator has explicitly excluded from that channel.
The issue is fixed in versions: 2.0.18, 2.1.15, 2.2.6 and above.
If an immediate upgrade is not possible, decorate the PaymentMethodChangerInterface service to re-validate the chosen payment method against the channel’s supported methods. See the full workaround in the advisory.
The original security advisory has been published on GitHub at Sylius/Sylius repository.
When the cart page is open in the browser and the underlying order becomes completed in the background (e.g. an admin changes its status, or the customer finalizes payment in another tab), the cart Live Component remains unaware of the state change. Clearing the cart then calls manager->remove() on the completed order and permanently deletes it; removing an item or changing a quantity mutates the completed order. The customer’s order data is irreversibly corrupted or lost even though the order has already been placed and paid for. The same vector can be triggered deliberately by an authenticated customer to alter quantities beyond what was paid for.
The issue is fixed in versions: 2.0.18, 2.1.15, 2.2.6 and above.
If an immediate upgrade is not possible, override the cart FormComponent at the project level so that any order in the completed checkout state is treated as a fresh cart and can no longer be mutated or deleted. See the full workaround in the advisory.
We would like to extend our gratitude to the researchers who responsibly disclosed these vulnerabilities:
These fixes address areas that directly affect the customer journey and store operations, including payments, order access, and order completion.
We recommend updating your Sylius installation as soon as you can. Sharing these fixes with others in the community also helps keep the whole ecosystem safer for everyone.We would like to thank everyone who participated in responsible disclosure of these vulnerabilities. If you believe you have found a security vulnerability in Sylius, please do not post it publicly. Instead, report it to [email protected].
Sylius Plus 
