StyleSmuggler w Magento i Adobe Commerce. Zero‑day RCE aktywnie wykorzystywany w atakach

5 września 2026 Sansec opisał StyleSmuggler – podatność zero‑day w Magento i Adobe Commerce, która umożliwia zdalne wykonanie kodu bez uwierzytelnienia. Problem od początku nie był wyłącznie teoretyczny. Pierwsze potwierdzone wykorzystanie podatności miało miejsce już 4 września, a w kolejnych dniach Sansec obserwował następne ataki i nowe warianty malware’u.

Materiał powstał na bazie oficjalnej analizy Sansec Forensics Team. Oryginalny artykuł znajdziesz tutaj: https://sansec.io/research/stylesmuggler

7 września Adobe opublikowało awaryjny hotfix dla podatności, która otrzymała oznaczenie CVE‑2026‑75650 oraz maksymalną ocenę CVSS 10.0. Adobe nadało biuletynowi APSB26‑146 najwyższy priorytet i potwierdziło aktywne wykorzystanie luki.

Według aktualnych informacji podatne są wersje Magento Open Source i Adobe Commerce od 2.4.4 do 2.4.9 włącznie. Samo wdrożenie poprawki nie kończy jednak analizy incydentu – ataki trwały przez około trzy dni, zanim hotfix został udostępniony.

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.

Co dokładnie jest podatne?

Według najnowszej aktualizacji Sansec podatność dotyczy wersji Magento Open Source i Adobe Commerce od 2.4.4 do 2.4.9 włącznie.

Sansec odtworzył pełny, niewymagający uwierzytelnienia łańcuch ataku na czystych instalacjach Magento Open Source 2.4.7, 2.4.8 i 2.4.9. Pierwszy zidentyfikowany zaatakowany sklep działał natomiast na 2.4.6‑p15 z wdrożonymi poprawkami bezpieczeństwa z lipca i sierpnia 2026.

7 września Sansec Shield zablokował również próbę wykorzystania StyleSmuggler przeciwko sklepowi działającemu na 2.4.7‑p10. To pokazuje, że wcześniejszy, aktualny patch level nie stanowił ochrony przed tą podatnością.

Sansec zaznacza również, że przeniesienie sesji do Redis lub bazy danych nie blokuje całego łańcucha ataku – napastnicy obserwowani podczas kampanii potrafili zmieniać sposób wykorzystania podatności.

Jak działa 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.

Nie trzeba nawet otworzyć maila o nieudanej płatności

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.

Dlaczego StyleSmuggler jest tak groźny?

Najważniejsze trzy elementy to:

• atak nie wymaga uwierzytelnienia,
• prowadzi do Remote Code Execution,
• podatność jest już aktywnie wykorzystywana.

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.

Backdoor udaje normalny proces systemowy

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.

Komunikacja C2 wygląda jak zwykły NTP

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.:

• identyfikator implantu,
• hostname,
• nazwa użytkownika,
• wersja systemu operacyjnego,
• wykorzystanie pamięci,
• wykorzystanie dysku,
• uptime,
• informacja, czy malware działa jako root,
• wersja implantu.

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.

Sansec obserwuje również drugiego atakującego

7 września Sansec zidentyfikował działania kolejnego, niezależnego aktora wykorzystującego StyleSmuggler jako punkt wejścia do środowiska Magento.

W tym przypadku napastnik pozostawiał webshell PHP w katalogu pub/media, m.in. pod ścieżką przypominającą:

pub/media/catalog/product/cache/ss_<10hex>/sync_<10hex>.php

Przed właściwym atakiem wykonywany był również reconnaissance sprawdzający m.in. system operacyjny, użytkownika PHP oraz możliwość zapisu do pub/media.

Dlatego Sansec rekomenduje dodatkowo sprawdzenie katalogu media pod kątem nietypowych plików PHP:

find pub/media ‑name '*.php'

Sam znaleziony plik PHP wymaga oczywiście analizy w kontekście konkretnego środowiska, ale nietypowy kod wykonywalny w pub/media powinien zostać potraktowany jako sygnał wymagający pilnej weryfikacji.

Co wiemy o skali ataków?

StyleSmuggler nie jest podatnością znalezioną podczas audytu i opublikowaną przed rozpoczęciem ataków. Kolejność była odwrotna.

Według osi czasu Sansec:

• 6 września – pojawia się wariant implantu fc‑cache, wersja 2.1.4,
• 7 września – Sansec obserwuje drugiego, niezależnego atakującego umieszczającego PHP webshell,
• 7 września, 17:30 UTC – zablokowana zostaje próba przeciwko sklepowi 2.4.7‑p10,
• 7 września – pojawia się wariant implantu chronyd, wersja 2.1.5,
• 7 września, 20:20 UTC – Adobe publikuje APSB26‑146 i hotfix VULN‑39341 dla CVE‑2026‑75650,
• 8 września – Scandiweb publikuje backport poprawki dla 41 niewspieranych wydań Magento od 2.2.0 do 2.4.3‑p3.

Adobe opublikowało poprawkę dla CVE‑2026‑75650

7 września 2026 Adobe opublikowało biuletyn APSB26‑146 oraz awaryjny hotfix dla StyleSmuggler. Podatność otrzymała oznaczenie CVE‑2026‑75650, ocenę CVSS 10.0 oraz najwyższy priorytet Adobe – Priority 1.

Poprawka została udostępniona jako hotfix, a nie pełne wydanie Magento. Adobe wskazuje pakiet:

VULN‑39341‑composer‑patches.zip

który należy pobrać z repo.magento.com i wdrożyć jako composer patch.

Poprawność instalacji można zweryfikować poleceniem:

vendor/bin/magento‑patches ‑n status | grep "39341\|Status"

Adobe przetestowało hotfix dla wydań z sierpnia 2026 w gałęziach 2.4.4‑2.4.9. Starsze wydania należące do tych samych gałęzi również są podatne, ale poprawka nie została na nich zweryfikowana przez Adobe.

Najważniejsze jest jednak to, że wdrożenie hotfixa zamyka podatność, ale nie usuwa skutków wcześniejszego włamania. StyleSmuggler był aktywnie wykorzystywany przez około trzy dni przed pojawieniem się oficjalnej poprawki.

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

Co trzeba zrobić teraz?

1. Wdrożyć oficjalny hotfix Adobe

Oficjalna poprawka dla StyleSmuggler jest już dostępna, dlatego jej wdrożenie powinno być obecnie pierwszym krokiem dla podatnych środowisk.

Adobe udostępniło hotfix VULN‑39341 dla CVE‑2026‑75650. Po wdrożeniu należy również potwierdzić, że poprawka została prawidłowo zastosowana.

WAF, reverse proxy i inne mechanizmy ochronne nadal są ważnymi warstwami bezpieczeństwa, ale po publikacji oficjalnego fixa nie powinny być traktowane jako alternatywa dla aktualizacji Magento.

2. Nie czekać wyłącznie na patch

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.

3. Sprawdzić, czy sklep nie został już zaatakowany

To równie ważne jak zablokowanie kolejnych prób.

Sansec wskazuje przede wszystkim na podejrzane procesy:

[kworker/u:8:0]

fc‑cache

chronyd

Ten ostatni wariant jest szczególnie interesujący, ponieważ wykorzystuje nazwę prawdziwego demona synchronizacji czasu w systemach Linux. Samo występowanie procesu chronyd nie jest więc dowodem kompromitacji – znaczenie ma jego lokalizacja, zachowanie i powiązane wskaźniki.

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 /tmp/.chrony‑*/chronyd

ps ‑eo pid,comm,args | grep ‑iE 'kworker|fc‑cache|chronyd'

grep ‑ril 'x_trace_' var/report/

Sansec ostrzega też, że część wariantów chronyd może działać bez wpisu widocznego przez crontab ‑l, więc pusty crontab nie daje pewności, że host jest czysty.

4. Sprawdzić mechanizmy persistence

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.

5. Zweryfikować ruch sieciowy pod kątem IoC

Sansec opublikował również wskaźniki kompromitacji związane z infrastrukturą napastników.

Wśród nich znajdują się m.in.:

• 247.cdnflare.xyz
• 209.141.43.95
• 99.84.67.186:443
• windwsecurity.run:443
• ntp.timesysnc.net:123
• time.microsft.run:123
• pool.microsft.studio:123
• ntp.timesync.to:123
• ntp.synctime.to:123
• ntp.syncstime.to:123
• 88.216.72.181

Szczegó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.

6. Zweryfikować nietypowe wiadomości o nieudanych płatnościach

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.

7. Przeprowadzić rotację klucza szyfrującego i poświadczeń

Adobe rekomenduje po wdrożeniu poprawki również rotację encryption key oraz wszystkich poświadczeń, które mogły być chronione przy jego użyciu.

Dotyczy to m.in. haseł administratorów, tokenów integracyjnych REST/SOAP/GraphQL, OAuth client secrets, danych dostępowych do bramek płatniczych i baz danych, kluczy SSH i deploy keys oraz kluczy API wykorzystywanych przez rozszerzenia.

Poświadczenia powinny zostać zmienione również u źródła, a nie wyłącznie w konfiguracji Magento. Sama rotacja encryption key nie unieważnia danych, które atakujący mógł wcześniej odczytać.

8. Jeśli znaleziono implant – potraktować sprawę jak incydent

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.

Jak ocenić ryzyko po stronie biznesu?

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:

• utrzymuje się w systemie,
• komunikuje się z infrastrukturą C2,
• czeka na polecenia,
• zbiera informacje o zainfekowanym serwerze,
• wykorzystuje mechanizmy utrudniające jego wykrycie.

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

StyleSmuggler – najważniejszy wniosek

Oficjalna poprawka Adobe jest już dostępna, ale to nie oznacza, że temat StyleSmuggler można zamknąć po jej instalacji.

Ataki rozpoczęły się około trzy dni przed publikacją hotfixa. W kolejnych dniach Sansec obserwował nowe warianty implantu oraz kolejnego aktora wykorzystującego tę samą podatność.

Dlatego działania trzeba prowadzić równolegle: wdrożyć poprawkę, zweryfikować jej instalację, sprawdzić środowisko pod kątem wcześniejszego naruszenia, przeanalizować aktualne IoC i przeprowadzić odpowiednią rotację poświadczeń.

W przypadku systemu odpowiadającego za sprzedaż samo pytanie:

„czy załataliśmy CVE‑2026‑75650?”

jest niewystarczające.

Równie ważne jest drugie:

„co działo się w naszym środowisku, zanim poprawka była dostępna?”