PolyShell: krytyczna luka w Magento i Adobe Commerce otwiera drogę do nieautoryzowanego RCE

securitybeztabu.pl 19 godzin temu

Wprowadzenie do problemu / definicja

PolyShell to nowo ujawniona podatność bezpieczeństwa dotycząca Magento Open Source oraz Adobe Commerce, która może umożliwić zdalne wykonanie kodu bez uwierzytelnienia. Problem wynika z niewystarczającej walidacji danych wejściowych w mechanizmie przesyłania plików przez REST API, wykorzystywanym przy obsłudze niestandardowych opcji produktów.

W praktyce oznacza to, iż atakujący może przesłać specjalnie przygotowany plik na serwer sklepu, a następnie – w zależności od konfiguracji środowiska – doprowadzić do wykonania złośliwego kodu, przejęcia sesji lub kompromitacji kont uprzywilejowanych.

W skrócie

PolyShell dotyczy stabilnych wdrożeń Magento 2 oraz Adobe Commerce.
Atak nie wymaga wcześniejszego logowania.
Wektor nadużycia opiera się na uploadzie pliku przez REST API do katalogu obsługującego opcje typu „file”.
W podatnych konfiguracjach możliwe jest RCE, a w innych scenariuszach stored XSS i przejęcie sesji.
W chwili ujawnienia poprawka była dostępna jedynie w gałęzi przedprodukcyjnej, co zwiększa okno narażenia dla środowisk produkcyjnych.

Kontekst / historia

Informacje o luce PolyShell pojawiły się w marcu 2026 roku. Badacze wskazali, iż źródło problemu tkwi w logice obecnej w platformie od bardzo wczesnych wersji Magento 2, co sugeruje długotrwałą ekspozycję wielu sklepów internetowych.

Choć w momencie publikacji nie było szeroko potwierdzonych przypadków masowego wykorzystania podatności w środowiskach produkcyjnych, sama technika ataku zaczęła już krążyć w obiegu. To istotny sygnał ostrzegawczy, ponieważ podobne ujawnienia często gwałtownie prowadzą do automatyzacji skanowania i prób eksploatacji.

Znaczenie problemu dodatkowo zwiększa popularność Magento i Adobe Commerce w sektorze e-commerce. Platformy te obsługują płatności, dane klientów, procesy logistyczne i integracje biznesowe, przez co są atrakcyjnym celem dla cyberprzestępców zainteresowanych kradzieżą danych, osadzaniem webshelli lub przejmowaniem paneli administracyjnych.

Analiza techniczna

Technicznie podatność wiąże się z akceptowaniem przez REST API przesyłania plików w ramach niestandardowych opcji pozycji koszyka. Gdy produkt posiada opcję typu plik, aplikacja przetwarza obiekt file_info, który może zawierać dane zakodowane w Base64, deklarowany typ MIME oraz nazwę pliku. Następnie plik jest zapisywany na serwerze w katalogu pub/media/custom_options/quote/.

Kluczowe ryzyko wynika z połączenia dwóch elementów: możliwości zapisania pliku przez nieuwierzytelnionego użytkownika oraz zależności bezpieczeństwa od konfiguracji serwera WWW. Atakujący może przygotować plik poliglotyczny, czyli taki, który wygląda jak nieszkodliwy zasób, ale może również zostać potraktowany jako skrypt wykonywalny. Właśnie stąd pochodzi nazwa PolyShell.

Jeżeli konfiguracja nginx lub Apache dopuszcza błędną interpretację takich plików, możliwe staje się zdalne wykonanie kodu. W innych scenariuszach przesłany plik może pełnić funkcję nośnika stored XSS, co otwiera drogę do przejęcia sesji lub kont administracyjnych. choćby jeżeli aktualnie wykonanie kodu jest zablokowane, trwałe zapisanie ładunku na dysku przez cały czas stanowi zagrożenie, ponieważ późniejsze zmiany w infrastrukturze mogą „uaktywnić” wcześniej osadzony plik.

Warto dodać, iż opisana ścieżka dotyczy REST API. Według opublikowanych analiz GraphQL korzysta z odmiennej logiki przetwarzania i nie był podatny na ten konkretny wariant ataku.

Konsekwencje / ryzyko

Udana eksploatacja PolyShell może prowadzić do pełnej kompromitacji sklepu internetowego. W najbardziej niebezpiecznym scenariuszu atakujący uzyskuje zdalne wykonanie kodu na serwerze aplikacyjnym, co może umożliwić przejęcie kontroli nad systemem oraz dalszy ruch boczny w infrastrukturze.

instalację webshella,
trwałe osadzenie backdoora,
kradzież danych klientów,
dostęp do panelu administracyjnego,
modyfikację procesu płatności i zamówień,
eskalację dostępu do innych systemów.

Równie groźny pozostaje wariant stored XSS. Przejęcie sesji administratora może pozwolić na wykonywanie operacji w imieniu uprzywilejowanego użytkownika, zmianę konfiguracji sklepu, manipulację cenami lub integracjami z usługami zewnętrznymi. Dla organizacji oznacza to nie tylko ryzyko techniczne, ale także straty finansowe, naruszenie zaufania klientów i potencjalne konsekwencje regulacyjne.

Rekomendacje

Administratorzy Magento i Adobe Commerce powinni potraktować PolyShell jako problem wysokiego priorytetu i wdrożyć działania ograniczające ryzyko bez oczekiwania na pełny cykl aktualizacji.

Zablokować dostęp HTTP do katalogu pub/media/custom_options/ oraz upewnić się, iż reguły serwera nie są nadpisywane przez bardziej ogólne dopasowania.
Przeprowadzić przegląd konfiguracji nginx i Apache pod kątem obsługi plików PHP, reguł location, .htaccess, mapowań FastCGI i wyjątków dla katalogów mediów.
Przeskanować środowisko w poszukiwaniu nieautoryzowanych plików, webshelli, backdoorów i śladów nietypowych żądań REST API.
Wdrożyć tymczasowe reguły WAF lub IPS monitorujące i blokujące żądania do endpointów REST związanych z uploadem plików.
Zwiększyć poziom logowania dla operacji uploadu i korelować zdarzenia z próbami dostępu do katalogów mediów.
Przygotować plan szybkiego wdrożenia oficjalnej poprawki natychmiast po jej udostępnieniu dla wersji produkcyjnych.
Rozważyć rotację poświadczeń administracyjnych oraz przegląd integralności aplikacji, zwłaszcza w środowiskach przetwarzających duży wolumen danych klientów.

Podsumowanie

PolyShell pokazuje, jak pozornie ograniczony mechanizm uploadu plików może przerodzić się w krytyczny wektor przejęcia sklepu internetowego. Połączenie nieuwierzytelnionego przesyłania plików, trwałego zapisu na serwerze oraz zależności od lokalnej konfiguracji infrastruktury sprawia, iż ryzyko należy oceniać jako wysokie.

Dla organizacji korzystających z Magento i Adobe Commerce najważniejsze są w tej chwili kontrole kompensacyjne, audyt konfiguracji, aktywne poszukiwanie śladów kompromitacji oraz gotowość do natychmiastowego wdrożenia poprawki. choćby bez potwierdzonej masowej kampanii ataków wszystko wskazuje na to, iż automatyzacja prób eksploatacji może być jedynie kwestią czasu.