Wprowadzenie do problemu / definicja
W ekosystemie e-commerce ujawniono groźną lukę typu zero-day dotyczącą Magento Open Source oraz Adobe Commerce. Podatność ma umożliwiać zdalne wykonanie kodu bez uwierzytelnienia, co w praktyce otwiera drogę do pełnego przejęcia serwera sklepu, wdrożenia trwałego backdoora oraz dalszych działań po stronie atakującego.
To szczególnie niebezpieczny scenariusz, ponieważ platformy te obsługują zamówienia, konta klientów, dane osobowe oraz procesy płatnicze. Każda skuteczna kompromitacja może więc mieć bezpośredni wpływ zarówno na ciągłość działania biznesu, jak i na bezpieczeństwo danych.
W skrócie
Badacze bezpieczeństwa alarmują, że luka jest aktywnie wykorzystywana w rzeczywistych atakach na sklepy internetowe oparte o Magento i Adobe Commerce. Z opublikowanych analiz wynika, że atak pozwala uruchomić złośliwy kod PHP, a następnie osadzić trwały mechanizm dostępu działający w tle.
- atak nie wymaga uwierzytelnienia,
- możliwa jest trwała infekcja środowiska,
- zagrożone mogą być także systemy z aktualnymi poprawkami,
- w chwili ujawnienia problemu brakowało oficjalnej łatki producenta.
Kontekst / historia
Incydent został nagłośniony na początku września 2026 roku, gdy firmy specjalizujące się w bezpieczeństwie e-commerce zaczęły publikować obserwacje dotyczące rzeczywistych włamań. Wstępne ustalenia wskazują, że kampania była prowadzona przeciwko aktywnym sklepom internetowym, a czas między próbą ataku a kompromitacją bywał bardzo krótki.
Istotne jest to, że ofiarami miały być nie tylko starsze i zaniedbane wdrożenia, lecz także instalacje utrzymywane na relatywnie nowych wersjach oraz z bieżącym poziomem łatek dla danej gałęzi. Taki obraz sugeruje nowy łańcuch ataku, a nie jedynie wykorzystanie znanych, dawno załatanych błędów.
Równolegle pojawiły się niezależne analizy zespołów reagowania i operatorów infrastruktury, które potwierdziły realne wykorzystanie podatności w środowiskach produkcyjnych. Dzięki temu społeczność bezpieczeństwa otrzymała pierwsze wskaźniki kompromitacji, hipotezy dotyczące przebiegu ataku oraz doraźne sposoby ograniczania ryzyka.
Analiza techniczna
Dostępne analizy wskazują, że atak ma charakter wieloetapowy. W pierwszej fazie napastnik wprowadza kontrolowany kod PHP do pliku zapisywanego przez aplikację. Mechanizm ten przypomina zatruwanie logów lub innych plików generowanych natywnie przez platformę.
W kolejnym etapie aplikacja zostaje skłoniona do wykonania wcześniej zapisanego kodu w toku standardowego przetwarzania wewnętrznych funkcji. To utrudnia wykrycie, ponieważ łańcuch wykorzystuje komponenty obecne w systemie i nie zawsze generuje oczywiste symptomy typowe dla prostych exploitów.
Po uruchomieniu droppera wdrażany jest właściwy payload odpowiedzialny za utrzymanie dostępu. Złośliwe artefakty nie muszą znajdować się wyłącznie w katalogu aplikacji. Mogą być umieszczane również w katalogu domowym użytkownika serwisu, lokalizacjach tymczasowych lub innych mniej monitorowanych ścieżkach systemowych.
Raportowane były też przypadki utrwalania infekcji przy użyciu zadań cron, które odtwarzały złośliwy proces po jego usunięciu. Wskaźniki kompromitacji obejmowały między innymi procesy podszywające się pod legalne wątki systemowe, ukryte pliki binarne oraz nietypowe wpisy w harmonogramie zadań.
W analizach pojawia się również rola GraphQL. Tymczasowe zalecenia obejmują możliwość jego wyłączenia tam, gdzie nie jest niezbędny biznesowo. Nie stanowi to jeszcze pełnego potwierdzenia całego przebiegu ataku dla wszystkich przypadków, ale sugeruje, że interfejsy API mogą odgrywać ważną rolę w bieżącej kampanii.
Konsekwencje / ryzyko
Najpoważniejszą konsekwencją tej podatności jest możliwość nieautoryzowanego wykonania kodu na serwerze sklepu. Samo uzyskanie RCE oznacza, że napastnik może instalować malware, kraść sekrety aplikacyjne, modyfikować logikę sklepu, manipulować zamówieniami lub przygotowywać grunt pod osadzenie skimmerów płatniczych.
Ryzyko rośnie ze względu na trwałość i skrytość infekcji. Jeśli backdoor działa poza webrootem i jest automatycznie odtwarzany przez cron, standardowe czyszczenie ograniczone do plików aplikacji może nie usunąć wszystkich elementów kompromitacji. To zwiększa prawdopodobieństwo ponownego przejęcia środowiska.
Dla firm handlowych dochodzi jeszcze wymiar zgodności, odpowiedzialności i reputacji. Sklep internetowy przetwarza dane osobowe, informacje o zamówieniach oraz często dane powiązane z płatnościami, dlatego każdy przypadek nieautoryzowanego dostępu do serwera powinien być traktowany jako incydent wysokiego ryzyka wymagający pełnej analizy powłamaniowej.
Rekomendacje
Administratorzy Magento i Adobe Commerce powinni potraktować sytuację jako incydent o wysokim priorytecie. W pierwszej kolejności należy ustalić, czy GraphQL jest rzeczywiście niezbędny dla działania sklepu. Jeśli nie, warto rozważyć jego czasowe wyłączenie do momentu wdrożenia oficjalnej poprawki lub potwierdzenia skuteczności innych zabezpieczeń.
Niezbędne jest rozszerzone polowanie na wskaźniki kompromitacji, obejmujące nie tylko katalog aplikacji, lecz także katalog domowy użytkownika serwisu, lokalizacje tymczasowe oraz zadania cron. Szczególną uwagę należy zwrócić na procesy imitujące wątki systemowe, ukryte binaria oraz nietypowe wpisy uruchamiane cyklicznie.
- przeanalizować logi aplikacyjne i serwerowe pod kątem nietypowych żądań,
- sprawdzić procesy działające pod użytkownikiem serwisu,
- zweryfikować integralność plików poza webrootem,
- przejrzeć cron i spool crontab,
- zresetować hasła administracyjne oraz przeprowadzić rotację kluczy i sekretów,
- unieważnić aktywne sesje użytkowników i administratorów.
Z perspektywy hardeningu warto ograniczyć możliwość uruchamiania procesów potomnych z poziomu PHP, przejrzeć konfigurację disable_functions oraz rozważyć montowanie katalogów tymczasowych z opcją noexec. Trzeba jednak podkreślić, że są to działania ograniczające skutki ataku, a nie pełna naprawa samej podatności.
Jeżeli istnieje choćby podejrzenie skutecznej kompromitacji, organizacja powinna uruchomić pełną procedurę reagowania na incydent: izolację systemu, zabezpieczenie artefaktów, analizę pamięci i procesów, odbudowę środowiska z zaufanego źródła oraz ponowną walidację wszystkich mechanizmów dostępu.
Podsumowanie
Nowa luka zero-day w Magento i Adobe Commerce stanowi jedno z najpoważniejszych bieżących zagrożeń dla operatorów sklepów internetowych. Kluczowym problemem jest możliwość zdalnego wykonania kodu bez uwierzytelnienia oraz wdrożenia trwałego backdoora, który może działać poza standardowym zakresem monitoringu aplikacyjnego.
Dla zespołów bezpieczeństwa oznacza to konieczność szybkiego przejścia z trybu prewencji do aktywnej detekcji i ograniczania skutków. W praktyce najważniejsze są szybkie wykrywanie wskaźników kompromitacji, redukcja powierzchni ataku, twarde zabezpieczenia systemowe oraz gotowość do pełnej analizy powłamaniowej.
Źródła
- Unpatched Magento and Adobe Commerce Zero-Day Exploited to Backdoor Online Stores — https://thehackernews.com/2026/09/unpatched-magento-and-adobe-commerce.html
- Sansec Advisory: StyleSmuggler — https://sansec.io/research/stylesmuggler
- Adobe Commerce Security Bulletin Index — https://helpx.adobe.com/security/products/magento.html
- Disrex Incident Response Repository — https://github.com/disrex/magento-stylesmuggler-response
- Graycore Mitigation Module — https://github.com/graycoreio/magento2-stylesmuggler