CVE-2026-53639
MediumCVSS 6.3Exploitation Probability (EPSS)
Low risk44th percentile - higher than 44% of all known CVEs
Summary
Sylius, an open-source eCommerce framework on Symfony, contains a vulnerability in versions from 2.0.0 to 2.0.17, 2.1.14, and 2.2.5. The GET and PUT API endpoints for payment requests do not verify resource ownership based on the hash, allowing an attacker to read payment and order data and modify redirect fields. A similar issue affects payment creation, where order ownership is not checked.
Risk Assessment
An attacker who obtains a payment hash (e.g., from logs or shared links) can access full order details, including addresses and customer email, and redirect the buyer to a malicious site after payment, potentially leading to data theft or session hijacking.
Recommendation
Immediately upgrade Sylius to version 2.0.18, 2.1.15, or 2.2.6. If upgrading is not possible, apply the workaround by adding query extensions and decorators to verify resource ownership.
Other vulnerabilities in Sylius
See all- CVE-2026-108724Medium
Sylius through 2.3.0 contains an authorization bypass vulnerability that allows unauthenticated attackers to read unmoderated and rejected product reviews because the AcceptedExtension filter is not applied to the item operation. Attackers can enumerate sequential ids on GET /api/v2/shop/product-reviews/{id} to retrieve review titles, ratings, comments, timestamps and author first names, bypassing merchant moderation.
- CVE-2026-100872High
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.
- CVE-2026-100871High
Sylius versions before 1.12.25, 1.13.17, 1.14.20, 2.1.16, and 2.2.9 fail to include firewall identification in JWT tokens issued by separate Admin and Shop API endpoints. Attackers can register a shop customer account using an administrator's email address and obtain a token that the Admin API resolves to that administrator, granting full administrative access.
- CVE-2026-100870High
Sylius versions before 1.12.25, 1.13.17, 1.14.20, 2.1.16, and 2.2.9 build administrator password-reset links using the request Host header without validation, allowing unauthenticated attackers to redirect reset tokens to attacker-controlled domains. Attackers can request password resets for known administrator email addresses with forged Host headers to intercept valid reset tokens and take over administrator accounts.
- CVE-2026-100869Medium
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.
- CVE-2026-53638Medium
Sylius, an Open Source eCommerce Framework on Symfony, contains an authorization bypass vulnerability in the shop account API. The PATCH /api/v2/shop/account/orders/{tokenValue}/payments/{paymentId} endpoint does not validate that the chosen payment method is enabled for the order's channel, allowing an authenticated customer to assign any globally enabled payment method to their order, including methods excluded by the store operator.
- CVE-2026-53637Medium
Sylius, an Open Source eCommerce Framework on Symfony, contains an improper workflow enforcement vulnerability in the cart FormComponent. When an order is completed while its cart page remains open, the stale LiveComponent does not detect the order's changed state and continues to permit cart actions, allowing an authenticated customer to modify or permanently delete an already completed order.
Original NVD description (English source)
Sylius is an Open Source eCommerce Framework on Symfony. Starting in version 2.0.0 and prior to version 2.0.18, 2.1.15, and 2.2.6, the `GET /api/v2/shop/payment-requests/{hash}` and `PUT /api/v2/shop/payment-requests/{hash}` endpoints look up the payment request solely by the hash from the URL. No ownership check is performed against the authenticated customer or the underlying order. An attacker who obtains a payment request hash can read the payment request and, through the `payment` IRI in the response, recover the underlying order's `tokenValue` (which itself grants access to the full order, items, addresses, customer email, totals); and/or update the payment request payload (e.g. `target_path`, `after_path`). These fields are used by the front-end controller to redirect the user after the payment, so an attacker can flip them to an attacker-controlled URL and intercept the buyer. The hash is a UUID, so it has to be obtained out-of-band (logs, shared links, referrer headers, a co-located client), but once it is known no other credential is required, neither authentication nor knowledge of the order token. The creation endpoint `POST /api/v2/shop/orders/{tokenValue}/payment-requests` shares the same flaw: it resolves the target order solely from the `tokenValue` in the URL without verifying that the caller owns the order. The issue is fixed in versions 2.0.18, 2.1.15, and 2.2.6. As a workaround, add a query extension that filters the `GET` operation; decorate the `PUT` state provider, guard the `POST` creation endpoint with a command-bus middleware, and wire the services.
Vulnerability data from NVD (NIST) · CISA KEV · EPSS