CVE-2026-53639: 
PHP vulnerability analysis and mitigation

CVE-2026-53639 is an Insecure Direct Object Reference (IDOR) vulnerability in the Sylius e-commerce platform's Shop Payment Request API endpoints, classified as Authorization Bypass Through User-Controlled Key (CWE-639). The affected endpoints — GET /api/v2/shop/payment-requests/{hash}, PUT /api/v2/shop/payment-requests/{hash}, and POST /api/v2/shop/orders/{tokenValue}/payment-requests — perform no ownership verification against the authenticated customer or underlying order. It affects sylius/sylius versions >= 2.0.0 < 2.0.18, >= 2.1.0 < 2.1.15, and >= 2.2.0 < 2.2.6. The vulnerability was first published on June 2, 2026, and added to the GitHub Advisory Database on July 9, 2026. It carries a CVSS v4.0 base score of 6.3 (Medium) (GitHub Advisory, Sylius Advisory).

The root cause is missing authorization logic (CWE-639) in three Shop API endpoints: the GET and PUT endpoints resolve a payment request solely by its UUID hash from the URL, and the POST creation endpoint resolves the target order solely from the tokenValue URL parameter — none of these verify that the caller owns the referenced resource. An attacker who obtains a payment request UUID hash (via logs, referrer headers, shared links, or a co-located client) can issue unauthenticated HTTP requests to read or modify the payment request without any additional credentials. The PUT endpoint is particularly dangerous because it allows modification of target_path and after_path fields, which the front-end controller uses to redirect users after payment completion, enabling open redirect attacks. The POST endpoint similarly allows any caller knowing an order's tokenValue to create payment requests against orders they do not own (GitHub Advisory, Sylius Advisory).

Successful exploitation allows an attacker to read full order details — including items, shipping addresses, customer email, and order totals — by recovering the order's tokenValue from the payment IRI in the GET response. Additionally, an attacker can manipulate payment redirect URLs (target_path, after_path) to point to attacker-controlled domains, enabling phishing or interception of buyers immediately after payment. The POST endpoint flaw allows unauthorized creation of payment requests against arbitrary orders, potentially disrupting the payment flow for other customers. While there is no direct availability impact, the combination of data exposure and redirect manipulation creates significant fraud and account-takeover risk for e-commerce deployments (GitHub Advisory).

No public proof-of-concept exploit code or evidence of in-the-wild exploitation has been reported as of the advisory date. The primary precondition is obtaining a valid payment request UUID hash out-of-band (e.g., from server logs, referrer headers, or shared URLs), which limits opportunistic mass exploitation but does not prevent targeted attacks. The CVE status is listed as "Reserved" and no EPSS score or CISA KEV catalog entry has been identified. The vulnerability requires no authentication and no user interaction once the hash is known, making it straightforward to exploit for a motivated attacker with access to the hash (GitHub Advisory, Sylius Advisory).

1. Obtain a payment request UUID hash: Acquire the hash out-of-band — for example, by monitoring HTTP referrer headers when a payment link is shared, accessing application or web server logs, or intercepting traffic from a co-located client.
2. Read the payment request (GET): Send an unauthenticated HTTP GET request to GET /api/v2/shop/payment-requests/{hash} using the obtained UUID. No authentication token or session is required.
3. Extract order token: Parse the JSON response to locate the payment IRI field, which contains or leads to the order's tokenValue. Use this token to query the full order details (items, addresses, customer email, totals).
4. Modify redirect URLs (PUT): Send an unauthenticated HTTP PUT request to PUT /api/v2/shop/payment-requests/{hash} with a modified payload setting target_path and/or after_path to an attacker-controlled URL (e.g., https://attacker.example.com/phish).
5. Intercept the buyer: When the legitimate customer completes payment, the front-end controller reads the tampered redirect fields and sends the buyer to the attacker's URL, enabling credential phishing, session hijacking, or fraud (GitHub Advisory, Sylius Advisory).

• Network: Unauthenticated or anomalous HTTP GET/PUT requests to /api/v2/shop/payment-requests/{hash} from IP addresses not associated with the order's customer session; POST requests to /api/v2/shop/orders/{tokenValue}/payment-requests from unexpected sources.
• Logs: Web server or application logs showing repeated access to payment request endpoints with different UUIDs from the same IP; access to payment request endpoints without a corresponding authenticated session cookie or bearer token.
• Application Behavior: Payment redirect URLs (target_path, after_path) in payment request records changed to external or unexpected domains; customers reporting being redirected to unfamiliar sites after completing payment.
• Order Data: Unexpected tokenValue lookups in order repository logs; order detail queries originating from IPs or sessions not associated with the order owner (GitHub Advisory).

Upgrade sylius/sylius to patched versions 2.0.18, 2.1.15, or 2.2.6 as the primary remediation (GitHub Advisory). For deployments that cannot upgrade immediately, Sylius provides a detailed multi-step workaround that enforces ownership checks on all three affected endpoints: (1) add a Doctrine ORM query extension (PaymentRequestOwnershipExtension) to filter GET results by the authenticated user's customer; (2) decorate the PUT state provider (PaymentRequestOwnershipProvider) to return null for unauthorized access; (3) add a Symfony Messenger middleware (PaymentRequestOwnershipMiddleware) to guard the POST command-bus operation; (4) wire all services in config/services.yaml and config/packages/messenger.yaml; and (5) clear the application cache with bin/console cache:clear. Full workaround code is provided in the official advisory (Sylius Advisory).

The vulnerability was responsibly disclosed by Fase Rais Baradika (@baradika) and Anshu Chimala (@achimala), and Sylius acknowledged their contributions in the official advisory. No significant broader media coverage or notable public researcher commentary beyond the official advisory has been identified at this time (Sylius Advisory).