Wprowadzenie do problemu / definicja
W ekosystemie Magento Open Source i Adobe Commerce ujawniono krytyczną podatność określaną jako PolyShell. Luka dotyczy mechanizmu przesyłania plików przez REST API i pozwala nieautoryzowanemu atakującemu na zapisanie dowolnego pliku w środowisku sklepu. W zależności od konfiguracji serwera WWW oraz sposobu obsługi przesłanych zasobów może to prowadzić do zdalnego wykonania kodu, przejęcia sesji administratora lub trwałego osadzenia złośliwego ładunku.
Z perspektywy bezpieczeństwa aplikacji webowych jest to szczególnie niebezpieczny przypadek, ponieważ łączy błąd logiki biznesowej z niewystarczającą walidacją danych wejściowych oraz ryzykiem wynikającym z lokalnej konfiguracji Nginx lub Apache. Oznacza to, iż wpływ podatności może być różny w zależności od wdrożenia, ale w części środowisk skutki mogą być krytyczne.
W skrócie
PolyShell umożliwia przesłanie pliku do sklepu bez wcześniejszego uwierzytelnienia. Mechanizm nadużywa obsługi opcji typu plikowego w koszyku zakupowym, gdzie aplikacja przyjmuje dane zakodowane w Base64, deklarowany typ MIME oraz nazwę pliku.
- atak nie wymaga logowania,
- plik może zostać zapisany w katalogu mediów sklepu,
- w określonych konfiguracjach możliwe jest RCE,
- w innych scenariuszach realne jest stored XSS i przejęcie kont,
- zagrożenie obejmuje szeroki zakres instalacji Magento 2 i Adobe Commerce.
Kontekst / historia
Badacze bezpieczeństwa wskazują, iż problem był obecny od bardzo wczesnych wersji Magento 2. Choć poprawka została uwzględniona w nowszej linii rozwojowej, przez pewien czas wiele aktywnie używanych środowisk produkcyjnych pozostawało narażonych, zwłaszcza tam, gdzie wdrożenia opierały się na niestandardowym hostingu i modyfikowanej konfiguracji warstwy HTTP.
To istotny kontekst dla branży e-commerce. W praktyce bezpieczeństwo sklepu internetowego zależy nie tylko od samego kodu aplikacji, ale także od sposobu mapowania ścieżek URL, reguł reverse proxy, obsługi rozszerzeń plików oraz przekazywania żądań do interpretera PHP. W efekcie identyczna luka aplikacyjna może w jednym środowisku skończyć się jedynie zapisem pliku, a w innym pełnym przejęciem serwera.
Analiza techniczna
Źródłem problemu jest sposób obsługi niestandardowych opcji produktu dodawanego do koszyka przez REST API. Gdy aplikacja przetwarza opcję plikową, akceptuje strukturę zawierającą nazwę pliku, jego zawartość oraz metadane. Mechanizm zapisuje taki obiekt w lokalizacji przeznaczonej na pliki opcji niestandardowych, co otwiera drogę do nadużycia funkcji uploadu.
Nazwa PolyShell nawiązuje do użycia plików poliglotycznych, czyli takich, które jednocześnie mogą wyglądać jak obraz lub inny pozornie nieszkodliwy zasób, a przy tym zawierać kod wykonywalny albo skrypt służący do późniejszego uruchomienia w przeglądarce ofiary. Tego typu technika zwiększa szansę obejścia prostych mechanizmów walidacji opartych tylko na rozszerzeniu, deklarowanym typie MIME lub podstawowym sprawdzeniu struktury pliku.
Scenariusz zdalnego wykonania kodu staje się możliwy wtedy, gdy konfiguracja serwera WWW dopuszcza interpretację przesłanego pliku jako kodu PHP. Może to wynikać z błędnych reguł lokalizacji, zbyt szerokiego dopasowania wzorców, niewłaściwego routingu do FastCGI albo niezamierzonego dziedziczenia polityk bezpieczeństwa w katalogu mediów. W takim wariancie napastnik może uruchomić web shell, a następnie przejść do dalszych działań poeksploatacyjnych.
Drugi istotny scenariusz dotyczy stored XSS. o ile przesłany plik lub jego zawartość zostaną później wyrenderowane w kontekście HTML lub JavaScript, atakujący może przejąć sesję administratora, wykonać operacje w jego imieniu, a choćby doprowadzić do dalszej eskalacji uprawnień. W środowisku Magento taki wektor jest szczególnie groźny ze względu na dostęp panelu administracyjnego do zamówień, danych klientów, konfiguracji płatności i integracji zewnętrznych.
Warto podkreślić, iż samo zablokowanie bezpośredniego dostępu HTTP do katalogu uploadu nie rozwiązuje problemu w pełni. Ogranicza to możliwość natychmiastowego wykorzystania ładunku, ale nie eliminuje ryzyka zapisu złośliwego pliku na dysku. Taki plik może zostać aktywowany później po zmianie konfiguracji, migracji środowiska lub błędzie administracyjnym.
Konsekwencje / ryzyko
Dla operatorów sklepów internetowych PolyShell stanowi zagrożenie o bardzo wysokiej krytyczności. W najgorszym przypadku skutki obejmują zarówno kompromitację infrastruktury, jak i naruszenie danych oraz ciągłości działania.
- zdalne wykonanie kodu na serwerze aplikacyjnym,
- przejęcie kont administracyjnych i użytkowników,
- instalację web shelli i trwałych backdoorów,
- kradzież danych klientów oraz informacji o zamówieniach,
- manipulację checkoutem i integracjami płatniczymi,
- wdrożenie skimmerów kart płatniczych,
- straty finansowe, reputacyjne i regulacyjne.
Ryzyko biznesowe jest szczególnie duże w sektorze e-commerce, gdzie incydent techniczny gwałtownie przekłada się na przestój operacyjny, utratę zaufania klientów i koszty reagowania. Publiczne ujawnienie mechanizmu ataku dodatkowo zwiększa prawdopodobieństwo powstania zautomatyzowanych skanerów i prób masowej eksploatacji.
Rekomendacje
Organizacje korzystające z Magento lub Adobe Commerce powinny potraktować tę podatność priorytetowo i wdrożyć wielowarstwowe działania ochronne. najważniejsze jest nie tylko zastosowanie poprawek producenta, ale także zweryfikowanie rzeczywistej konfiguracji serwera.
- przeprowadzić inwentaryzację wersji i potwierdzić wdrożenie poprawki bezpieczeństwa,
- zablokować wykonywanie skryptów w katalogu pub/media/custom_options/,
- przejrzeć reguły Nginx i Apache dotyczące location, obsługi rozszerzeń PHP i mapowania do FastCGI,
- wdrożyć WAF lub inne mechanizmy filtrujące próby nadużycia uploadu przez REST API,
- przeskanować środowisko pod kątem web shelli, backdoorów i nieautoryzowanych plików w katalogach mediów,
- przeanalizować logi REST API, zwłaszcza żądania związane z koszykiem i opcjami niestandardowymi,
- zweryfikować konta administracyjne, zadania cron i integralność plików aplikacji,
- przygotować plan awaryjny obejmujący rotację poświadczeń oraz kontrolę integracji płatniczych.
Z perspektywy zespołów SOC i IR szczególnie istotne będą artefakty związane z nietypowymi nazwami plików, zawartością zakodowaną w Base64, żądaniami do REST API bez uzasadnienia biznesowego oraz aktywnością w lokalizacji przechowującej pliki opcji niestandardowych.
Podsumowanie
PolyShell pokazuje, iż pozornie ograniczona funkcja uploadu może stać się punktem wejścia do pełnego przejęcia środowiska e-commerce. O skali zagrożenia decyduje nie tylko sam błąd aplikacyjny, ale także konfiguracja serwera WWW, sposób renderowania zasobów oraz praktyki administracyjne obowiązujące w danym wdrożeniu.
Dla firm utrzymujących sklepy oparte na Magento i Adobe Commerce priorytetem powinny być aktualizacja, twarde ograniczenie uploadów, przegląd konfiguracji Nginx i Apache oraz aktywne poszukiwanie śladów wcześniejszej kompromitacji. W praktyce to właśnie połączenie patch managementu, hardeningu i detekcji daje największą szansę na ograniczenie skutków tej klasy podatności.
Źródła
- The Hacker News — https://thehackernews.com/2026/03/magento-polyshell-flaw-enables.html
- Sansec — Magento PolyShell: unrestricted file upload in Magento and Adobe Commerce — https://sansec.io/research/magento-polyshell
- Adobe Security Bulletin APSB25-94 — https://helpx.adobe.com/security/products/magento/apsb25-94.html