https://vulnerability.circl.lu Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Sun, 04 Oct 2026 14:37:58 +0000 https://vulnerability.circl.lu/vuln/fkie_cve-2026-53639 <p>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&#39;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` st…</p> <p>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&#39;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` st…</p> https://vulnerability.circl.lu/vuln/fkie_cve-2026-53639 https://vulnerability.circl.lu/vuln/ghsa-mr9r-h354-966r <p><strong>Affected:</strong> Packagist: sylius/sylius</p> <p>### Impact 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.</p> <p>An attacker who obtains a payment request hash can:</p> <p>- read the payment request and, through the `payment` IRI in the response, recover the underlying order&#39;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.</p> <p>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.</p> <p>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.</p> <p>### Patches The issue is fixed in versions: 2.0.18, 2.1.15, 2.2.6.</p> <p>### Workarounds Until you can upgrade, apply the following workaround. It enforces ownership on the existing endpoints, so that:</p> <p>- an authenticated shop user may only access payment requests of their…</p> <p><strong>Affected:</strong> Packagist: sylius/sylius</p> <p>### Impact 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.</p> <p>An attacker who obtains a payment request hash can:</p> <p>- read the payment request and, through the `payment` IRI in the response, recover the underlying order&#39;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.</p> <p>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.</p> <p>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.</p> <p>### Patches The issue is fixed in versions: 2.0.18, 2.1.15, 2.2.6.</p> <p>### Workarounds Until you can upgrade, apply the following workaround. It enforces ownership on the existing endpoints, so that:</p> <p>- an authenticated shop user may only access payment requests of their…</p> https://vulnerability.circl.lu/vuln/ghsa-mr9r-h354-966r