Support 24/7: +48 61 646 07 77
5 września 2026 Sansec opisał StyleSmuggler – nową podatność zero‑day w Magento i Adobe Commerce, która umożliwia zdalne wykonanie kodu bez uwierzytelnienia. Problem jest szczególnie poważny, bo nie mówimy o teoretycznym scenariuszu. Pierwsze potwierdzone wykorzystanie podatności miało miejsce już 4 września, a Sansec wykrył kolejne zainfekowane sklepy.
Materiał powstał na bazie oficjalnej analizy Sansec Forensics Team. Oryginalny artykuł znajdziesz tutaj: https://sansec.io/research/stylesmuggler
Badacze odtworzyli pełny łańcuch ataku na czystych instalacjach Magento Open Source 2.4.7, 2.4.8 i 2.4.9. Pierwszy zidentyfikowany przez nich zaatakowany sklep działał natomiast na 2.4.6‑p15, miał wdrożone poprawki bezpieczeństwa z lipca i sierpnia 2026, a security:patch‑status nie wskazywał brakujących aktualizacji.
Na moment przygotowania tego materiału nie ma jeszcze oficjalnej poprawki Adobe dla StyleSmuggler. Kolejny security release Adobe jest zaplanowany na 8 września 2026, jednak Sansec zaznacza, że nie ma jeszcze potwierdzenia, czy obejmie właśnie tę podatność.
Z tego artykułu dowiesz się:
StyleSmuggler jest szczególnie niebezpieczny z jednego powodu: atakujący nie potrzebuje konta ani wcześniejszego dostępu do sklepu. Udany exploit może doprowadzić bezpośrednio do wykonania kodu na serwerze, a następnie uruchomienia trwałego backdoora komunikującego się z infrastrukturą napastników.
Według Sansec problem dotyczy aktualnych wersji Magento i Adobe Commerce, w tym najnowszego Magento 2.4.9.
Badacze potwierdzili pełny, niewymagający uwierzytelnienia łańcuch ataku na czystych instalacjach:
Co więcej, pierwszy znaleziony przez Sansec zaatakowany sklep korzystał z Magento 2.4.6‑p15 i miał zainstalowane aktualne poprawki bezpieczeństwa z lipca oraz sierpnia 2026.
To oznacza, że samo posiadanie aktualnego Magento i pozytywny wynik security:patch‑status nie gwarantują obecnie ochrony przed StyleSmuggler.
Sedno podatności znajduje się w systemie szablonów Magento. StyleSmuggler wykorzystuje właściwości styles, aby wprowadzić złośliwy kod do systemu templatingowego i ominąć istniejące mechanizmy ochronne. Według analizy Sansec cały atak przebiega w dwóch głównych etapach.
Najpierw napastnik doprowadza do wstrzyknięcia kodu PHP – Sansec jako przykład wskazuje wygenerowanie odpowiednio przygotowanego failure report.
Następnie Magento samo wykonuje wcześniej wstrzyknięty kod podczas generowania wiadomości związanej z nieudaną płatnością.
W ruchu obserwowanym przez Sansec jednym z charakterystycznych elementów ataku jest żądanie:
POST /graphql?styles[...]
oraz późniejsze wywołania związane m.in. z obsługą nieudanej transakcji.
Kluczowe jest jednak coś innego! Atak nie wymaga zalogowanego użytkownika. Jeżeli cały łańcuch zakończy się powodzeniem, napastnik uzyskuje możliwość wykonania kodu na serwerze.
Ciekawym elementem mechanizmu StyleSmuggler jest wykorzystanie standardowej wiadomości Magento „Payment Transaction Failed Reminder”.
Atak celowo doprowadza do jej wygenerowania, ponieważ wykonanie złośliwego kodu następuje podczas renderowania wiadomości przez Magento.
Nie oznacza to jednak żadnego phishingu i nie wymaga interakcji użytkownika.
Nikt nie musi otworzyć wiadomości.
Co więcej, według Sansec atak może się udać nawet wtedy, gdy samo dostarczenie maila zakończy się błędem. Dlatego brak takich wiadomości w skrzynce nie jest dowodem na to, że środowisko nie zostało zaatakowane.
Z drugiej strony nietypowy wzrost liczby maili o nieudanych płatnościach powinien być sygnałem do dokładniejszej weryfikacji środowiska. Trzeba jednak pamiętać, że takie wiadomości mogą oczywiście powstawać również podczas zwykłych, odrzuconych transakcji.
Najważniejsze trzy elementy to:
To zestaw, który znacząco zmienia sposób, w jaki należy podejść do incydentu.
Jeżeli atakujący uzyska możliwość wykonywania kodu na serwerze Magento, samo późniejsze zamknięcie pierwotnej podatności nie oznacza jeszcze, że środowisko jest bezpieczne.
I właśnie to Sansec obserwuje w praktyce.
Po skutecznym wykorzystaniu StyleSmuggler na serwerze uruchamiany jest backdoor działający jako proces w tle. Badacze opisują go jako niewielki program napisany w Rust, który łączy się z serwerem Command & Control i czeka na dalsze instrukcje.
Według stanu wiedzy Sansec z 6 września nie ma jeszcze dowodów, że backdoor został wykorzystany do kolejnych działań na zainfekowanych systemach. To jednak nie zmienia podstawowego problemu: atakujący pozostawia sobie trwały kanał dostępu do infrastruktury sklepu.
Pierwszy analizowany przez Sansec wariant implantu ukrywał się pod nazwą:
[kworker/u:8:0]
To nazwa celowo przypominająca normalny kernel worker systemu Linux.
6 września Sansec zidentyfikował kolejne wersje malware’u dla architektur x86‑64 i ARM64. Tym razem proces podszywa się pod:
fc‑cache
Implant kopiuje się do:
~/.cache/fontconfig/fc‑cache
i dodaje wpis w cronie uruchamiający go ponownie dwa razy na godzinę:
13,43 * * * *
Dzięki temu samo zabicie procesu nie musi oznaczać usunięcia zagrożenia – malware może zostać ponownie uruchomione.
Jeszcze ciekawszy jest sposób komunikacji nowszego wariantu z infrastrukturą napastników.
Co 60 sekund implant odpytuje domenę ntp.timesync.to i wysyła pakiety UDP na port 123 – czyli standardowy port używany przez NTP.
Ruch został przygotowany tak, żeby przypominał komunikację związaną z synchronizacją czasu.
W rzeczywistości w pakietach przesyłane są informacje o zainfekowanym serwerze, m.in.:
To sprytna technika ukrywania komunikacji. Ruch UDP na porcie 123 kierowany do domeny wyglądającej jak serwer czasu może nie wzbudzać podejrzeń w środowisku, w którym monitoring ruchu wychodzącego jest ograniczony.
StyleSmuggler nie jest podatnością znalezioną podczas audytu i opublikowaną przed rozpoczęciem ataków. Kolejność była odwrotna.
Według osi czasu Sansec:
fc‑cache,Na moment przygotowania tego materiału – 7 września 2026 – Adobe nie opublikowało jeszcze oficjalnej poprawki dla StyleSmuggler.
Sansec informuje, że kolejny security release Adobe został zaplanowany na 8 września, ale jednocześnie zaznacza, że nie ma jeszcze pewności, czy będzie zawierał poprawkę dotyczącą tej konkretnej podatności.
Dlatego dziś nie można sprowadzić rekomendacji do prostego: „zaktualizuj Magento do wersji X”.
Takiej wersji naprawczej dla StyleSmuggler jeszcze nie wskazano.
Do czasu publikacji oficjalnego rozwiązania trzeba skupić się na ograniczeniu możliwości wykorzystania podatności i sprawdzeniu, czy środowisko nie zostało już wcześniej skompromitowane.
Przy zero‑dayu nie ma komfortu czekania na idealne rozwiązanie. Trzeba działać warstwowo – ograniczyć znany wektor ataku, sprawdzić środowisko pod kątem kompromitacji i zaangażować developerów odpowiedzialnych za aplikację. W przypadku StyleSmuggler szczególnie ważne jest, żeby nie pomylić mitygacji z pełnym rozwiązaniem problemu. WAF może pomóc, ale nie zastępuje poprawki Magento.
Mikołaj Mielczarek, Customer Project Management Lead w Centurii
Przy aktywnie wykorzystywanym zero‑day czekanie na oficjalną aktualizację nie powinno być jedyną strategią.
Sansec rekomenduje zastosowanie mechanizmu blokującego StyleSmuggler. W przypadku klientów Sansec jest nim Shield.
Jeżeli środowisko nie korzysta z takiego zabezpieczenia, Sansec wskazuje możliwość tymczasowego wyłączenia GraphQL do momentu pojawienia się oficjalnego fixa Adobe.
W praktyce decyzja o wyłączeniu GraphQL musi oczywiście uwzględniać architekturę konkretnego sklepu – w środowiskach headless lub rozwiązaniach intensywnie korzystających z GraphQL taka operacja może wpływać na działanie aplikacji.
To równie ważne jak zablokowanie kolejnych prób.
Sansec wskazuje przede wszystkim na podejrzane procesy:
[kworker/u:8:0]
oraz:
fc‑cache
Do podstawowej weryfikacji badacze podają m.in.:
crontab ‑l | grep ‑i gvfsd
ls ‑la ~/.local/share/.gvfsd/ ~/.cache/fontconfig/fc‑cache /tmp/.kw_* /tmp/.cache_* /tmp/.gvfsd‑* /tmp/.fc‑*/fc‑cache /tmp/fc‑cache 2>/dev/null
ps ‑eo pid,comm,args | grep ‑iE 'kworker|fc‑cache'
grep ‑ril 'x_trace_' var/report/
Sama obecność procesu o podobnej nazwie nie powinna być analizowana w oderwaniu od kontekstu, ale znalezienie wskazanych przez Sansec artefaktów jest mocnym sygnałem wymagającym dalszej analizy.
Wśród śladów opisywanych przez Sansec znajdują się m.in.:
~/.local/share/.gvfsd/gvfsd‑user
~/.cache/fontconfig/fc‑cache
/tmp/.kw_<random><random>
/tmp/.cache_<random><random>
/tmp/.fc_<8hex>.lock
oraz wpisy crona uruchamiające malware cyklicznie.
To ważne, bo nawet zatrzymanie aktualnie działającego procesu może nie wystarczyć, jeśli pozostawiony został mechanizm jego automatycznego ponownego uruchomienia.
Sansec opublikował również wskaźniki kompromitacji związane z infrastrukturą napastników.
Wśród nich znajdują się m.in.:
247.cdnflare.xyz209.141.43.9599.84.67.186:443windwsecurity.run:443ntp.timesysnc.net:123time.microsft.run:123pool.microsft.studio:123ntp.timesync.to:123ntp.synctime.to:123ntp.syncstime.to:12388.216.72.181Szczególną uwagę warto zwrócić na nietypowy ruch UDP/123 z serwera aplikacyjnego, ponieważ właśnie w ten sposób nowszy wariant implantu maskuje komunikację C2 jako synchronizację czasu.
Nagły wzrost wiadomości „Payment Transaction Failed Reminder” może być jednym z sygnałów wykorzystania podatności.
Nie jest to jednak samodzielny dowód włamania – takie wiadomości mogą powstawać również podczas normalnego działania sklepu.
Tak samo ich brak nie oznacza, że sklep jest bezpieczny, ponieważ wykonanie złośliwego kodu może nastąpić nawet wtedy, gdy wysłanie maila ostatecznie się nie powiedzie.
Sansec rekomenduje zmianę danych uwierzytelniających Magento, jeżeli w środowisku został odnaleziony podejrzany proces związany z kampanią.
Z perspektywy operacyjnej samo usunięcie jednego procesu nie powinno kończyć analizy. Jeżeli atakujący uzyskał RCE, trzeba ustalić, co wydarzyło się pomiędzy pierwszym dostępem a wykryciem incydentu i czy nie pozostały inne mechanizmy trwałego dostępu.
W przypadku StyleSmuggler nie warto zatrzymywać się na stwierdzeniu „Magento ma podatność”.
Technicznym skutkiem jest Remote Code Execution, czyli możliwość wykonywania kodu na serwerze aplikacyjnym.
Z biznesowej perspektywy oznacza to przede wszystkim możliwość utraty kontroli nad środowiskiem, na którym działa jeden z kluczowych systemów sprzedażowych firmy.
Jeżeli infrastruktura zostanie skompromitowana, potencjalne konsekwencje zależą już od zakresu dalszych działań napastnika, uprawnień procesu i konstrukcji całego środowiska.
Na dziś warto jednak zachować precyzję: Sansec nie potwierdził jeszcze wykorzystania obserwowanego backdoora do dalszych działań na ofiarach.
Wiemy natomiast, że implant:
To wystarczający powód, żeby temat potraktować priorytetowo.
StyleSmuggler dobrze pokazuje, że w przypadku e‑commerce bezpieczeństwo nie kończy się na serwerze. Przy zero‑dayu w Magento potrzebna jest szybka współpraca zespołu deweloperskiego, administratorów infrastruktury i samego klienta. Możemy ograniczać ryzyko na poziomie WAF, reverse proxy czy systemu operacyjnego, ale to nie zastępuje analizy aplikacji i poprawki producenta. Najważniejsze w pierwszych godzinach jest więc nie tylko wdrożenie mitygacji, ale również sprawdzenie, czy środowisko nie zostało już wcześniej naruszone.
Mikołaj Mielczarek, Customer Project Management Lead w Centuria
W przypadku klasycznej podatności scenariusz często wygląda prosto: pojawia się advisory, następnie poprawka i aktualizujemy środowisko.
Tutaj sytuacja jest inna.
Ataki rozpoczęły się przed publikacją analizy, a oficjalnego fixa Adobe jeszcze nie ma.
Dlatego najważniejsze działania trzeba prowadzić równolegle:
W przypadku systemu odpowiadającego za sprzedaż samo pytanie „czy mamy najnowszą wersję Magento?” jest dziś niewystarczające.
Trzeba jeszcze odpowiedzieć na drugie:
czy mamy pewność, że ktoś nie wykorzystał tej podatności wcześniej?
![Bezpieczeństwo środowisk testowych [krótki poradnik dla DevOps/SysOps]](https://centuria.pl/wp-content/uploads/2022/09/07-12-bezpieczenstwo-srodowisk-424x228.jpg)
