CVE-2026-53639
ŚrednieCVSS 6.3Streszczenie
Sylius, framework e-commerce oparty na Symfony, zawiera podatność w wersjach od 2.0.0 do 2.0.17, 2.1.14 i 2.2.5. Punkty końcowe API GET i PUT dla płatności nie weryfikują własności zasobu na podstawie hasha, co pozwala atakującemu na odczyt danych płatności i zamówienia oraz modyfikację pól przekierowań. Podobny problem dotyczy tworzenia płatności, gdzie nie sprawdza się właściciela zamówienia.
Ocena ryzyka
Atakujący, znając hash płatności (np. z logów lub udostępnionych linków), może uzyskać dostęp do pełnych danych zamówienia, w tym adresów i e-maila klienta, oraz przekierować kupującego na złośliwą stronę po płatności, co może prowadzić do kradzieży danych lub przejęcia sesji.
Rekomendacja
Zaleca się natychmiastową aktualizację Syliusa do wersji 2.0.18, 2.1.15 lub 2.2.6. Jeśli aktualizacja nie jest możliwa, należy wdrożyć obejście polegające na dodaniu rozszerzenia zapytań i dekoratorów weryfikujących własność zasobów.
Inne podatności w Sylius
Zobacz wszystkie- CVE-2026-53638Średnie
Sylius, framework e-commerce oparty na Symfony, zawiera podatność polegającą na obejściu autoryzacji w API konta sklepu. Endpoint PATCH /api/v2/shop/account/orders/{tokenValue}/payments/{paymentId} nie sprawdza, czy wybrana metoda płatności jest włączona dla kanału zamówienia, co pozwala uwierzytelnionemu klientowi przypisać dowolną globalnie włączoną metodę płatności do swojego zamówienia, w tym metody wykluczone przez operatora sklepu.
- CVE-2026-53637Średnie
Sylius, framework e-commerce oparty na Symfony, zawiera podatność polegającą na niewłaściwym egzekwowaniu przepływu pracy w komponencie koszyka FormComponent. Gdy zamówienie jest finalizowane, a strona koszyka pozostaje otwarta, nieaktualny LiveComponent nie wykrywa zmiany stanu zamówienia i nadal pozwala na akcje koszyka, umożliwiając uwierzytelnionemu klientowi modyfikację lub trwałe usunięcie już sfinalizowanego zamówienia.
Oryginalny opis (angielski, źródło NVD)
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.