Support 24/7: +48 61 646 07 77
17 marca 2026 Sansec opisał krytyczną podatność nazwaną PolyShell, która umożliwia przesłanie złośliwego pliku na sklep Magento lub Adobe Commerce przez REST API – bez logowania. W praktyce oznacza to, że atakujący może wgrać plik, który wygląda jak obrazek, ale zawiera wykonywalny kod PHP. Sansec zaobserwował później masowe wykorzystanie tej luki i podał, że do 30 marca próby ataku objęły 79,5% chronionych przez nich sklepów.
Materiał powstał na bazie oficjalnej analizy Sansec Forensics Team. Oryginalny artykuł znajdziesz tutaj: https://sansec.io/research/magento‑polyshell
Z tego artykułu dowiesz się:
To nie jest kolejna techniczna ciekawostka z security. To podatność, która może prowadzić do pełnego przejęcia sklepu, utrzymania trwałego dostępu na serwerze, a następnie do osadzenia malware’u w sklepie – także takiego, który uderza już bezpośrednio w klientów i płatności. Sansec opisał zarówno webshelle PHP, jak i późniejsze działania po kompromitacji, w tym backdoor accesson.php oraz loader JavaScript pobierający zewnętrzny malware.
Według Sansec podatne były wszystkie wersje Magento Open Source i Adobe Commerce do 2.4.9‑alpha2 włącznie. Dodatkowo skutki podatności mogły być znacznie gorsze w zależności od konfiguracji serwera WWW: od stored XSS w starszych wersjach lub przy niestandardowej konfiguracji, aż po pełne RCE przy określonych konfiguracjach nginx i Apache. Sansec wskazuje też, że podatny kod istniał od pierwszego wydania Magento 2.
Na dziś najważniejsza aktualizacja jest taka, że Adobe opublikowało już biuletyn APSB25‑94 oraz wersje naprawcze dla wspieranych gałęzi: m.in. Magento Open Source 2.4.8‑p3, 2.4.7‑p8, 2.4.6‑p13 oraz Adobe Commerce 2.4.8‑p3, 2.4.7‑p8, 2.4.6‑p13, 2.4.5‑p15 i 2.4.4‑p16.
Sedno problemu leży w obsłudze uploadu plików w custom options koszyka przez REST API. Magento przyjmuje obiekt file_info, zapisuje plik do pub/media/custom_options/quote/, ale – jak opisał Sansec – po drodze brakuje trzech krytycznych kontroli: walidacji option ID względem realnych opcji produktu, sprawdzenia czy dana opcja w ogóle jest typu file, oraz blokady niebezpiecznych rozszerzeń takich jak .php, .phtml czy .phar. Jedyną istotną walidacją jest sprawdzenie nagłówka obrazu, które da się obejść plikiem polyglot.
Najgroźniejsze są anonimowe endpointy guest cart:
POST /V1/guest‑carts/:cartId/items
oraz
PUT /V1/guest‑carts/:cartId/items/:itemId.
To właśnie one sprawiają, że exploit nie wymaga żadnych poświadczeń. Co ważne, Sansec zaznacza, że ścieżka GraphQL używa innego kodu i nie była podatna na ten konkretny wektor.
W najgorszym scenariuszu atakujący nie kończy na wrzuceniu pliku. Jeżeli konfiguracja serwera pozwala na wykonanie wgranego kodu, zyskuje zdalne wykonanie poleceń. Sansec pokazał przykłady aktywnie używanych payloadów: od webshella z autoryzacją po cookie, po prosty shell wykonujący komendy systemowe. Opisali też, że po uzyskaniu wykonania kodu napastnicy rozrzucają backdoor accesson.php po wielu katalogach projektu, żeby zwiększyć szansę przetrwania po częściowym czyszczeniu środowiska.
To bardzo ważny moment z perspektywy biznesu: nawet jeśli dziś zablokujesz sam wektor wejścia, atakujący mógł już wcześniej uzyskać dostęp do sklepu. A to oznacza, że samo patchowanie nie wystarczy. Trzeba jeszcze sprawdzić, czy ktoś nie zostawił po sobie trwałego dostępu.
Sansec opisał oś czasu, z której wynika, że pierwsze próby sondowania ruszyły 16 marca, aktywne ataki zaobserwowano 19 marca, 23 marca wystartował masowy scanning, a 30 marca firma raportowała już 79,5% chronionych sklepów objętych próbami wykorzystania podatności. Sansec opublikował też przykładowe adresy IP używane do skanowania oraz wskazał, że kampania była zautomatyzowana.
Dla merchantów i zespołów IT najważniejszy wniosek jest prosty – nie zakładaj, że „nas to pewnie ominęło”, tylko potraktuj temat jak incydent, który wymaga potwierdzenia braku śladów włamania.
To dziś podstawowy krok. Adobe wskazuje konkretne docelowe wersje w APSB25‑94 i rekomenduje aktualizację do najnowszych wydań w ramach wspieranych linii.
Sansec wyraźnie podkreśla, że skutki podatności zależą także od konfiguracji nginx lub Apache. Szczególnie trzeba upewnić się, że dostęp do pub/media/custom_options/ jest blokowany, a reguły nie są nadpisywane przez zbyt szerokie przekazywanie .php do FastCGI. W środowiskach Apache trzeba sprawdzić obecność i skuteczność odpowiednich reguł .htaccess.
Jeśli exploit mógł zostać użyty wcześniej, aktualizacja nie usunie już wrzuconych plików, backdoorów ani wstrzykniętego JavaScriptu. Sansec rekomenduje skanowanie środowiska pod kątem webshelli, backdoorów i innych artefaktów uzyskania dostępu.
Na podstawie analizy Sansec warto pilnie sprawdzić m.in.:
index.php, bypass.phtml, json‑shell.php, rce.php, accesson.php w nietypowych lokalizacjach, szczególnie poza standardowym upload directory,*/assets/images/accesson.php w wielu top‑level folderach projektu,lanhd6549tdhse.top w CMS blocks, stronach CMS i assetach frontendowych,pub/media/custom_options/quote/ pod kątem plików, które nie powinny się tam znaleźć.Sansec podaje też prostą komendę do szybkiego szukania jednego z artefaktów:
find /var/www ‑name 'accesson.php' ‑type f
Z perspektywy sklepu problem nie kończy się na serwerze. Jeśli doszło do wykonania kodu, ryzyko obejmuje także:
Sansec opisał już przypadek wykorzystania PolyShell jako wektora wejścia do nowego skimmera płatniczego opartego o WebRTC. To pokazuje, że ta podatność nie jest tylko „preludium do problemu” – ona już była wykorzystywana jako realny etap większych kampanii.
![Bezpieczeństwo środowisk testowych [krótki poradnik dla DevOps/SysOps]](https://centuria.pl/wp-content/uploads/2022/09/07-12-bezpieczenstwo-srodowisk-424x228.jpg)
