Co znajdziesz w tym artykule?
Wprowadzenie do problemu / definicja
PolyShell to krytyczna podatność affecting Magento Open Source 2 oraz Adobe Commerce, związana z mechanizmem przesyłania plików w interfejsie REST API. Luka może zostać wykorzystana do zdalnego wykonania kodu, przejęcia kont lub osadzenia złośliwego JavaScriptu w warstwie sklepu internetowego.
Skala zagrożenia jest szczególnie wysoka, ponieważ podatność dotyczy środowisk e-commerce przetwarzających dane klientów i płatności. W praktyce oznacza to ryzyko pełnego kompromitowania sklepu, a następnie wykorzystania go do kradzieży danych lub prowadzenia dalszych kampanii przestępczych.
W skrócie
- Masowe ataki wykorzystujące PolyShell rozpoczęły się 19 marca 2026 r.
- Ślady eksploatacji wykryto na 56,7% podatnych sklepów.
- Luka dotyczy uploadu plików przez REST API w Magento Open Source 2 i Adobe Commerce.
- Możliwym skutkiem jest zdalne wykonanie kodu, stored XSS oraz wdrożenie skimmera kart płatniczych.
- Poprawka została udostępniona w gałęzi 2.4.9-beta1, ale nie była jeszcze dostępna w stabilnym wydaniu produkcyjnym w momencie opisywanych zdarzeń.
Kontekst / historia
Magento od lat pozostaje atrakcyjnym celem dla cyberprzestępców ze względu na bezpośredni związek z procesami sprzedażowymi, danymi klientów i informacjami płatniczymi. Ataki na tę platformę często koncentrują się na przejmowaniu kont administracyjnych, wstrzykiwaniu złośliwego kodu oraz osadzaniu skimmerów płatniczych w frontendzie sklepu.
PolyShell wpisuje się w ten trend, ale wyróżnia się szybkością przejścia od publicznego ujawnienia do aktywnej, szeroko zakrojonej eksploatacji. Dwa dni po ujawnieniu szczegółów technicznych luka była już wykorzystywana na dużą skalę, co pokazuje, że atakujący dysponowali gotowymi narzędziami do automatyzacji skanowania i kompromitacji podatnych instalacji.
Analiza techniczna
Źródłem problemu jest niewystarczająca walidacja plików przesyłanych przez REST API w określonych scenariuszach związanych z opcjami niestandardowymi produktów dodawanych do koszyka. Mechanizm może zaakceptować plik, który przechodzi jedną warstwę kontroli, ale zawiera dodatkowy kod wykonywalny lub aktywną zawartość interpretowaną w innym kontekście.
Taki plik poliglotyczny może zostać wykorzystany do osiągnięcia zdalnego wykonania kodu, jeśli pozwala na to konfiguracja serwera i sposób obsługi przesłanych zasobów. W innych przypadkach możliwe jest zapisanie ładunku prowadzącego do stored XSS, a dalej do przejęcia sesji lub kont administracyjnych.
Zaobserwowane kampanie pokazały również użycie nowego typu skimmera kart płatniczych, który wykorzystuje WebRTC do eksfiltracji danych. Zamiast klasycznego ruchu HTTP złośliwy loader komunikuje się z infrastrukturą sterującą przez szyfrowany kanał DTLS/UDP, co może utrudniać wykrywanie przez część narzędzi bezpieczeństwa i systemów monitoringu sieciowego.
To sprawia, że PolyShell nie jest wyłącznie luką wejściową. W praktyce może stanowić pierwszy etap pełnego łańcucha ataku obejmującego uzyskanie dostępu, utrzymanie persystencji, osadzenie skimmera i długotrwałą kradzież danych płatniczych klientów.
Konsekwencje / ryzyko
Wpływ podatności na organizację może być bardzo poważny. Dla operatorów sklepów internetowych oznacza to nie tylko ryzyko technicznego naruszenia aplikacji, ale także realne skutki biznesowe, prawne i reputacyjne.
- kradzież danych kart płatniczych klientów,
- przejęcie kont użytkowników i administratorów,
- modyfikacja procesu zakupowego lub warstwy frontendowej,
- naruszenie integralności sklepu i utrata zaufania klientów,
- problemy zgodności z wymaganiami PCI DSS,
- straty finansowe, operacyjne i wizerunkowe.
Wysoki odsetek już zaatakowanych środowisk sugeruje, że wiele organizacji może mieć do czynienia nie tylko z ryzykiem podatności, ale z faktycznym incydentem bezpieczeństwa. Szczególnie groźne jest to, że skimmer oparty na WebRTC może działać bardziej dyskretnie niż tradycyjne implanty komunikujące się przez zwykły ruch HTTP(S).
Rekomendacje
Organizacje korzystające z Magento Open Source lub Adobe Commerce powinny potraktować PolyShell jako priorytet krytyczny i połączyć działania naprawcze z aktywnym polowaniem na ślady kompromitacji.
- niezwłocznie wdrożyć dostępne poprawki producenta lub oficjalne obejścia,
- przeanalizować konfigurację serwera WWW pod kątem możliwości wykonania przesłanych plików,
- sprawdzić logi aplikacyjne, serwerowe i WAF pod kątem nietypowych żądań do REST API,
- zweryfikować integralność plików JavaScript, motywów i szablonów sklepu,
- monitorować ruch wychodzący pod kątem nietypowej komunikacji UDP, DTLS i WebRTC,
- przejrzeć polityki CSP oraz mechanizmy ładowania skryptów,
- przeprowadzić rotację poświadczeń administracyjnych, tokenów i kluczy integracyjnych po podejrzeniu naruszenia,
- porównać wskaźniki kompromitacji z własną telemetrią,
- wdrożyć ciągły monitoring zmian w plikach i skanowanie sklepu z perspektywy klienta,
- uruchomić procedury incident response obejmujące izolację, analizę forensyczną i działania naprawcze.
Podsumowanie
PolyShell należy obecnie do najpoważniejszych zagrożeń dla środowisk Magento i Adobe Commerce. Łączy prosty do automatyzacji wektor wejścia z bardzo wysokim wpływem na bezpieczeństwo operacyjne i ciągłość sprzedaży.
Najbardziej niepokojące są dwa czynniki: szybka eskalacja do masowych ataków oraz wykorzystanie nowoczesnych technik kradzieży danych płatniczych, które utrudniają detekcję. Dla właścicieli sklepów oznacza to konieczność natychmiastowego ograniczenia ekspozycji oraz równoległego sprawdzenia, czy kompromitacja nie nastąpiła już wcześniej.