GHSA-mr9r-h354-966r Sylius: IDOR on Shop Payment Request API endpoints
ImpactThe `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);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.PatchesThe issue is fixed in versions: 2.0.18, 2.1.15, 2.2.6.WorkaroundsUntil you can upgrade, apply the following workaround. It enforces ownership on the existing endpoints, so that:an authenticated shop user may only access payment requests of their own orders;an anonymous caller may only access payment requests of guest orders (the order's customer has no associated user account);everyone else receives `404 Not Found`.Step 1. Add a query extension that filters the `GET` operationCreate file `src/ApiPlatform/QueryExtension/PaymentRequestOwnershipExtension.php`:Step 2. Decorate the `PUT` state providerCreate file `src/ApiPlatform/StateProvider/PaymentRequestOwnershipProvider.php`:Step 3. Guard the `POST` creation endpoint with a command-bus middlewareThe `POST /api/v2/shop/orders/{tokenValue}/payment-requests` operation is a `messenger: input` operation: it dispatches a `Sylius\Bundle\ApiBundle\Command\Payment\AddPaymentRequest` command whose `orderTokenValue` comes straight from the URL, so no query extension or state provider runs. Add a middleware on the Sylius command bus that loads the order, applies the same ownership rule, and aborts with `404` before the handler runs.Create file `src/Messenger/Middleware/PaymentRequestOwnershipMiddleware.php`:Step 4. Wire the servicesAppend to `config/services.yaml`:With the default Sylius-Standard `services.yaml` (`autowire: true`, `autoconfigure: true`) the two classes are already autoloaded, the block above only adds the tag and the decoration, which cannot be derived from the constructor signatures.Step 5. Register the middleware on the Sylius command busAdd to `config/packages/messenger.yaml`:Step 6. Clear the cacheReportersWe would like to extend our gratitude to the following individuals for their detailed reporting and responsible disclosure of this vulnerability:Fase Rais Baradika (@baradika)Anshu Chimala (@achimala)For more informationIf you have any questions or comments about this advisory:Open an issue in [Sylius issues](https://github.com/Sylius/Sylius/issues?q=sort%3Aupdated-desc+is%3Aissue+is%3Aopen)Email us at [security@sylius.com](mailto:security@sylius.com)
CVSS v4.0 score: 6.3