Sylius: IDOR on Shop Payment Request API endpoints

published 2026-07-09 4 mo ago modified 2026-09-09 1 mo ago also EUVD-2026-74285 , GHSA-mr9r-h354-966r

cvss: 6.3; version 4.0, CNA
cisa kev: Not listed; not in CISA's catalog
epss: 0.5%; EPSS 0.5% chance of exploitation in 30 days, percentile 45%
public exploits: 0; none known

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.

Patch / fix

fixed in 2

packagist sylius/sylius 2.0.18, 2.1.15, 2.2.6
sylius sylius 2.0.18, 2.1.15, 2.2.6

CISA SSVC

Exploitation: none
Automatable: no
Technical impact: partial
Assessed: 2 mo ago (2026-09-09)

Exploit prediction

0.54% chance of exploitation in the next 30 days, higher than 45% of all scored CVEs (FIRST EPSS, 2026-11-08).

CVSS scores

assigned by	version	score	vector
CNA	4.0	6.3	CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:L/VI:L/VA:N/SC:N/SI:N/SA:N
CNA	4.0	6.3	CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:L/VI:L/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X

Affected packages

ecosystem	package	affected	fixed in
packagist	sylius/sylius	>=2.0.0, <2.0.18 >=2.1.0, <2.1.15 >=2.2.0, <2.2.6	2.0.18 2.1.15 2.2.6

Affected products

Sylius Sylius

Classification

Weakness

CWE-639 Authorization Bypass Through User-Controlled Key

References

Sources

Fencer Vulns keeps one entry per vulnerability: the CVE id wins, then GHSA, and records that alias each other are merged, except that two CVEs always keep separate entries. The same data is available as JSON.

CPEs and fixed versions use Anchore's correction of NVD's data: Added CPE configurations because not yet analyzed by NVD.

Summary