CVE-2026-53639

Sylius: IDOR on Shop Payment Request API endpoints

MEDIUM
6.3
CVSS Score
Published: September 8, 2026 at 10:22 PM UTC
Updated: September 9, 2026 at 09:17 PM UTC
1 product affected across 1 vendorSylius

Using Sylius by Sylius?

Get instant alerts when new vulnerabilities affect Sylius - before attackers find them.

Real-time alertsTrack your software stackFree plan available
Severity
MEDIUM6.3
Exploit prediction
EPSS 0.5%
SSVC
No known exploit

Description

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.

Affected

Our own answer: ranges merged, affected separated from platform-only, with confidence and review flags.

60%
v < 2.0.18v < 2.1.15v < 2.2.6
Affected range stops below 2.0.18, so it looks safe — our inference, not a vendor statement
Affected range stops below 2.1.15, so it looks safe — our inference, not a vendor statement
Affected range stops below 2.2.6, so it looks safe — our inference, not a vendor statement

Remediation

No guide yet

No remediation guidance has been written for this CVE yet, and no fixed version or vendor advisory is recorded against it.

References (1)

SSVC — Action Prioritization

SSVCNo known exploitNot automatablePartial impact

SSVC signals action urgency (what to patch first), separate from CVSS which measures severity.

CVSS

6.3MEDIUMGitHub_M
Vector?

Quick Info

StatusDEFERRED
CWE
CWE-639

Get alerted

Stop reading CVE feeds looking for your own stack

Track the products you run and VulnTracker tells you when a new CVE affects them — with what is known about fixing it, and nothing about the rest.

Free plan, no card