StyleSmuggler: aktywnie wykorzystywana luka zero-day w Magento i Adobe Commerce
StyleSmuggler to aktywnie wykorzystywana luka zero-day (RCE) w Magento i Adobe Commerce. Wyjaśniamy, kogo dotyczy, jak sprawdzić, czy sklep jest zainfekowany, i co zrobić, zanim pojawi się oficjalny patch.

Aktualizacja (8 września 2026): 7 września 2026 Adobe wydało oficjalną poprawkę na tę lukę – biuletyn bezpieczeństwa APSB26-146 z numerem podatności CVE-2026-75650. Poprawką jest hotfix VULN-39341, a po jego wgraniu Adobe wymaga wymiany klucza szyfrującego oraz wszystkich poświadczeń, które mogły zostać nim zaszyfrowane lub ujawnione: haseł administratorów, tokenów integracji i API, kluczy bramek płatności, dostępów do bazy i serwera. Adobe potwierdza, że luka była wykorzystywana w atakach na sklepy. Pełna lista wersji i instrukcja wgrania poprawki: pomoc Adobe – APSB26-146. Jeśli prowadzisz sklep na Magento lub Adobe Commerce, zaktualizuj go teraz. Tekst poniżej opisuje sytuację sprzed wydania poprawki.
Jeśli prowadzisz sklep na Magento lub Adobe Commerce, ten artykuł jest pilny. Od 4 września 2026 roku trwają realne ataki na sklepy oparte o tę platformę, a na dzień publikacji (7 września 2026) Adobe nie wydało jeszcze oficjalnej poprawki. Co gorsza, aktualny poziom patchy w Twoim sklepie nie chroni przed tą luką. Poniżej wyjaśniamy, co się dzieje, jak w kilka minut sprawdzić, czy Twój serwer został zaatakowany, i co zrobić już teraz.
Czym jest StyleSmuggler i kogo dotyczy
StyleSmuggler to nazwa nadana nowej, krytycznej luce w Magento, ujawnionej 5 września 2026 roku przez zespół Sansec Forensics Team. Jej najważniejsze cechy:
- Typ: zdalne wykonanie kodu bez uwierzytelnienia (RCE). Atakujący nie musi mieć żadnego konta w sklepie, by przejąć serwer.
- Zero-day: w chwili ujawnienia nie było ani oficjalnego numeru CVE, ani łatki od Adobe.
- Status: luka jest aktywnie wykorzystywana. Ataki trwają, pierwsze potwierdzone przypadki odnotowano 4 września 2026 roku około 22:20 UTC.
Najgroźniejsze jest to, że aktualność patchy nie jest tu żadnym zabezpieczeniem. Sansec potwierdził pełny łańcuch ataku na czystych instalacjach 2.4.7, 2.4.8 i 2.4.9, a pierwszą znaną ofiarą był sklep na 2.4.6-p15 z kompletem poprawek z lipca i sierpnia 2026 oraz czystym wynikiem bin/magento security:patch-status. Zagrożone są więc wszystkie aktualnie wspierane wersje Magento Open Source i Adobe Commerce, niezależnie od tego, jak sumiennie były łatane.
Luka nie omija sklepów B2B. Adobe Commerce z modułem B2B jest podatny tak samo jak zwykła instalacja B2C, a w tym pierwszym przypadku stawka jest wyższa: cenniki kontraktowe, dane firm, zamówienia hurtowe i pozycja w łańcuchu dostaw.
Jak działa atak
Opisujemy mechanizm ogólnie, bez gotowego kodu, tak by pomóc w obronie, a nie w ataku. Atak ma dwa etapy i wykorzystuje wbudowane funkcje Magento:
- Zatrucie. Atakujący wstrzykuje złośliwy kod PHP w miejsce, które Magento samo zapisuje na dysku, na przykład do raportów błędów lub logów.
- Wykonanie. Następnie zmusza platformę do uruchomienia zatrutego kodu przez system szablonów Magento, wykorzystując między innymi właściwość
styles, dyrektywy{{block}}i łańcuch obiektów kończący się na dołączeniu pliku wskazanego przez atakującego.
Charakterystyczny jest tu wektor e-mailowy. Atak bywa powiązany z generowaniem wiadomości typu „Payment Transaction Failed Reminder”, a złośliwy kod wykonuje się już podczas renderowania takiego e-maila. Nikt nie musi go otwierać, a atak może się powieść nawet wtedy, gdy sama wysyłka wiadomości się nie uda.
W logach dostępu ślady widać najczęściej jako żądania POST /graphql?styles[...]= oraz ruch na endpointach związanych z PayPal transparent response i ładowaniem sekcji klienta (customer section load).
Co dzieje się po udanym ataku
Skutkiem jest pełna kontrola nad serwerem. Sansec obserwuje instalację implantu (backdoora) napisanego w języku Rust, który maskuje się pod nazwami systemowych procesów, takimi jak [kworker/u:8:0], a w nowszym wariancie z 6 września jako fc-cache. Implant zapewnia sobie trwałość przez wpisy w cronie (na przykład co 5 minut lub dwa razy na godzinę) i komunikuje się z serwerem sterującym, między innymi po WebSocket oraz ruchem udającym NTP na porcie 123.
Na dziś nie ma publicznych doniesień o masowym wykorzystaniu tych backdoorów do dalszych działań, takich jak skimming kart. To jednak żadne pocieszenie: napastnik ma na serwerze pełną swobodę i może zdecydować się na kolejny krok w dowolnej chwili.
Jak sprawdzić, czy Twój sklep padł ofiarą
Poniższe polecenia są tylko do odczytu, niczego nie zmieniają i możesz je uruchomić od razu. Uruchamiaj je na serwerze sklepu, w katalogu głównym instalacji Magento tam, gdzie dotyczy to plików projektu.
Podejrzane procesy udające zadania jądra:
ps -eo pid,user,rss,args --no-headers | awk '$4 ~ /^\[/ && $2 != "root"'
Wpisy w cronie pozostawione przez implant:
crontab -l | grep -i gvfsd
Charakterystyczne pliki i katalogi:
ls -la ~/.local/share/.gvfsd/ ~/.cache/fontconfig/fc-cache /tmp/.kw_* /tmp/.fc-* 2>/dev/null
Ślady wstrzykniętego kodu PHP w raportach i logach:
grep -ril 'x_trace_\|X_TRACE_\|<?php' var/report/ var/log/
Dodatkowo w logach dostępu szukaj ciągów styles[, styles%5B, odwołań do generatorClass czy cdnflare. Jeśli którekolwiek z tych sprawdzeń zwróci wynik, potraktuj serwer jako potencjalnie skompromitowany i przejdź do sekcji o reagowaniu.
Co zrobić już teraz
Ponieważ Adobe nie wydało jeszcze łatki, obrona opiera się na mitygacjach tymczasowych. Najbliższy planowany biuletyn bezpieczeństwa Adobe przypada na 8 września 2026 roku, ale nie ma pewności, czy obejmie StyleSmuggler. Do czasu oficjalnej poprawki poziom patchy nie jest miarą bezpieczeństwa.
Zalecane działania zapobiegawcze:
- Włącz ochronę w czasie rzeczywistym. Sansec Shield blokuje znane warianty tego ataku od strony ruchu przychodzącego.
- Rozważ tymczasowe wyłączenie GraphQL, jeśli nie masz przed sklepem zapory aplikacyjnej (WAF). To rekomendacja samego Sansec, bo główny wektor idzie właśnie przez GraphQL.
- Do wykrywania implantów użyj skanera eComscan od Sansec.
- Nieoficjalne patche społecznościowe traktuj ostrożnie. Krążą awaryjne poprawki (między innymi od Disrex i graycore), które utwardzają skanery DI do trybu wyłącznie CLI i dokładają reguły nginx lub Apache. Nie są oficjalne, nie usuwają istniejącej infekcji i trzeba je najpierw przetestować na środowisku staging.
Jeśli wykryłeś oznaki kompromitacji, kolejność jest następująca: zabezpiecz dowody, usuń malware i ewentualne wtórne backdoory, zmień wszystkie hasła i klucze (panel administratora, baza danych, SSH, API), a następnie rozważ pełny audyt i odtworzenie sklepu z czystej kopii zapasowej sprzed ataku.
Warto też uważnie obserwować pocztę wychodzącą. Sygnałem ostrzegawczym są nagłe fale wiadomości „Payment Transaction Failed” oraz podejrzane e-maile z nierozwiniętymi znacznikami {{var ...}}, adresami w domenie .invalid albo błędami generowania treści.
Wybrane wskaźniki kompromitacji (IoC)
Procesy i pliki:
- procesy
[kworker/u:8:0]orazfc-cache ~/.local/share/.gvfsd/gvfsd-user~/.cache/fontconfig/fc-cache/tmp/.kw_*,/tmp/.fc-*
Sieć:
247.cdnflare.xyz,209.141.43.9599.84.67.186:443,windwsecurity.runntp.timesync.to,ntp.synctime.toi podobne (UDP123)- jedno ze źródeł ataków:
88.216.72.181
Przykładowy hash implantu:
e315687a1dfe61ef4a5a5642214db6d3b2b05d81391285eebc2af664641a26a7
Pamiętaj, że lista wskaźników się zmienia. Napastnicy już raz podmienili nazwę procesu i będą to robić dalej, więc brak trafienia na powyższą listę nie jest dowodem, że wszystko jest w porządku.
Dlaczego to ważne dla sklepów B2B i firm z PIM
StyleSmuggler dobrze pokazuje, że bezpieczeństwo platformy e-commerce to nie opcja, tylko fundament. Duży katalog, integracje z ERP, złożona polityka cenowa i wielu użytkowników nie chronią przed RCE. Wręcz przeciwnie: im bardziej rozbudowany sklep B2B, tym więcej wrażliwych danych trafia w ręce atakującego.
Jest w tym też lekcja dla firm, które porządkują dane produktowe. Nawet najlepszy system PIM nie pomoże, jeśli platforma sprzedażowa zostanie przejęta. Spójne dane produktowe i bezpieczna platforma to dwa filary skalowalnego B2B, których nie da się rozdzielić. Regularne aktualizacje, zapora aplikacyjna i monitoring procesów na serwerze to dziś standard, a nie dodatek.
Potrzebujesz pomocy przy aktualizacji lub audycie?
Jeśli nie masz pewności, czy Twój sklep jest bezpieczny, albo chcesz przejść przez powyższe sprawdzenia i mitygacje z kimś, kto robi to na co dzień, pomożemy. Zajmujemy się wsparciem i aktualizacją Magento oraz audytem sklepów Magento. Napisz do nas przez formularz kontaktowy, a wspólnie ustalimy, co zrobić w pierwszej kolejności.
Źródła
- Sansec, opis luki StyleSmuggler: sansec.io/research/stylesmuggler
- Oficjalna poprawka Adobe, wydana 7 września 2026: biuletyn APSB26-146 (CVE-2026-75650)
Artykuł opisuje stan na 7 września 2026 roku. Sytuacja zmienia się szybko, dlatego po ukazaniu się oficjalnego patcha zaktualizuj Magento najszybciej, jak to możliwe, i zweryfikuj serwer pod kątem wymienionych wskaźników.

Współzałożyciel i CEO Macopedia, ekspert w dziedzinie e-commerce, PIM, WMS i ERP. Od ponad 15 lat kształtuje rynek e-commerce, uczestnicząc w transformacji cyfrowej wielu przedsiębiorstw i wdrażając innowacyjne rozwiązania technologiczne. Jego artykuły dostarczają strategicznych i praktycznych wskazówek dla firm dążących do optymalizacji procesów i wzrostu w świecie cyfrowym.
Więcej artykułów tego autora →