Wprowadzenie do problemu / definicja
PolyShell to krytyczna podatność wykryta w REST API platform Magento Open Source oraz Adobe Commerce, która umożliwia nieautoryzowane przesyłanie plików na serwer sklepu. Problem dotyczy mechanizmu obsługi niestandardowych opcji produktowych typu „file” i może prowadzić do zapisania na dysku plików zawierających aktywny kod.
W praktyce oznacza to ryzyko zdalnego wykonania kodu, trwałego ataku XSS lub przygotowania środowiska do dalszej kompromitacji sklepu. Skala zagrożenia zależy od konfiguracji serwera WWW, sposobu obsługi katalogów uploadu oraz stopnia utwardzenia całej infrastruktury.
W skrócie
- Podatność pozwala na upload plików bez uwierzytelnienia przez REST API.
- Problem dotyczy Magento Open Source i Adobe Commerce.
- Atak może prowadzić do webshella, stored XSS lub trwałego osadzenia złośliwego pliku.
- Największe ryzyko występuje tam, gdzie katalog uploadu jest dostępny z poziomu serwera WWW.
- Remediacja wymaga zarówno aktualizacji, jak i utwardzenia konfiguracji.
Kontekst / historia
Magento od lat pozostaje jednym z najczęściej atakowanych systemów e-commerce. Powód jest prosty: przejęcie sklepu internetowego otwiera drogę do wycieku danych klientów, instalacji skimmerów płatniczych, przejęcia kont administracyjnych i modyfikacji treści sklepu.
PolyShell wpisuje się w ten krajobraz zagrożeń, ale wyróżnia się tym, iż wykorzystuje natywną funkcję API odpowiedzialną za obsługę plików. Według opublikowanych analiz podatny kod istniał od bardzo wczesnych wersji Magento 2, co oznacza, iż wiele środowisk mogło pozostawać narażonych przez długi czas bez wyraźnych symptomów incydentu.
Analiza techniczna
Istota problemu tkwi w sposobie, w jaki REST API przyjmuje dane plikowe osadzone w strukturze żądania jako obiekt file_info. Mechanizm pozwala przesłać zawartość pliku zakodowaną w Base64 razem z nazwą pliku i deklarowanym typem MIME, a następnie zapisuje ją w katalogu przeznaczonym dla niestandardowych opcji produktowych.
Krytyczny błąd polega na tym, iż taka ścieżka zapisu nie zawsze jest odpowiednio odizolowana od odczytu lub wykonania po stronie serwera WWW. jeżeli środowisko pozwala na interpretację przesłanego pliku jako kodu, atakujący może uzyskać webshell i trwały dostęp do systemu. choćby gdy wykonanie kodu jest zablokowane, złośliwy artefakt może zostać wykorzystany później, na przykład do stored XSS albo po zmianie konfiguracji serwera.
Nazwa PolyShell odnosi się do użycia plików poliglotycznych, czyli takich, które mogą wyglądać jak nieszkodliwe obrazy lub zasoby multimedialne, ale jednocześnie zawierają fragmenty kodu możliwe do uruchomienia lub wykonania w określonych warunkach. To utrudnia detekcję opartą wyłącznie na rozszerzeniu pliku lub zadeklarowanym MIME type.
Warto też podkreślić, iż problem został powiązany z określoną ścieżką REST API. Z dostępnych analiz wynika, iż analogiczny przepływ realizowany przez GraphQL nie jest podatny w ten sam sposób, co zawęża źródło ryzyka do konkretnego komponentu wejściowego aplikacji.
Konsekwencje / ryzyko
PolyShell należy traktować jako podatność o bardzo wysokim wpływie operacyjnym i biznesowym. Skutki skutecznego wykorzystania luki mogą wykraczać daleko poza sam nieautoryzowany upload pliku.
- Uzyskanie trwałego dostępu do serwera aplikacyjnego dzięki webshella.
- Przejęcie kont klientów lub administratorów przez stored XSS.
- Osadzenie skimmerów płatniczych i modyfikacja treści sklepu.
- Wykorzystanie sklepu jako punktu wejścia do dalszej penetracji infrastruktury.
- Ukrycie złośliwego payloadu na dysku do późniejszej aktywacji.
Szczególnie niebezpieczny jest fakt, iż choćby brak bezpośredniego wykonania plików nie eliminuje zagrożenia. Złośliwy plik może pozostać w systemie i zostać aktywowany po migracji, zmianie konfiguracji hostingu, odtworzeniu środowiska z kopii zapasowej lub błędnym wdrożeniu nowych reguł serwera.
Rekomendacje
Administratorzy Magento i Adobe Commerce powinni potraktować temat priorytetowo. Odpowiedź na to zagrożenie powinna obejmować zarówno remediację producenta, jak i dodatkowe warstwy ochronne po stronie organizacji.
- Niezwłocznie zaktualizować platformę do wersji zawierających poprawki bezpieczeństwa.
- Zweryfikować konfigurację katalogów uploadu, zwłaszcza w obrębie pub/media/custom_options/.
- Zablokować lub ściśle ograniczyć dostęp HTTP do lokalizacji przechowujących przesłane pliki.
- Wdrożyć reguły WAF i monitorowanie żądań REST API z podejrzanymi polami file_info.
- Przeskanować środowisko pod kątem śladów kompromitacji, webshelli i nietypowych artefaktów.
- Sprawdzić obecność wtórnych skutków incydentu, takich jak skimmery, nieautoryzowane konta czy backdoory w modułach.
- Wzmocnić monitoring integralności plików i egzekwować zasadę najmniejszych uprawnień.
Dobrą praktyką jest także ograniczenie ekspozycji REST API tylko do niezbędnych funkcji oraz regularna weryfikacja konfiguracji hostingu. W środowiskach e-commerce choćby pozornie drobna luka uploadowa może gwałtownie przerodzić się w pełnoskalowy incydent bezpieczeństwa.
Podsumowanie
PolyShell pokazuje, jak niebezpieczne może być połączenie natywnej funkcji uploadu z niewystarczającą walidacją wejścia i niejednorodną konfiguracją serwerów WWW. W przypadku Magento i Adobe Commerce podatność może prowadzić zarówno do zapisania złośliwego pliku, jak i do pełnej kompromitacji sklepu internetowego.
Najważniejsze działania to szybka aktualizacja, twarde ograniczenie dostępu do katalogów uploadu, wdrożenie ochrony aplikacyjnej oraz pełny przegląd środowiska pod kątem oznak naruszenia. To luka, którą należy oceniać nie tylko jako problem z uploadem plików, ale jako realny wektor RCE, stored XSS i trwałego osadzenia złośliwego kodu w infrastrukturze e-commerce.