4 września ktoś zaczął przejmować sklepy oparte na Magento. Nie przez słabe hasło administratora, nie przez zapomnianą aktualizację – przez lukę, o której nikt jeszcze nie wiedział. Style Smuggler (CVE-2026-75650) to luka w Magento, która pozwala atakującemu uruchomić własny kod na serwerze sklepu bez logowania i bez żadnej interakcji ze strony użytkownika.
Style Smuggler dostał ocenę krytyczności CVSS 10.0, czyli najwyższą z możliwych. Zagrożenie jest więc duże. Na szczęście 7 września Adobe opublikowało oficjalną poprawkę. Mamy więc już pierwszą linię obrony. To jednak może nie wystarczyć.
Jeśli Twój sklep stoi na Magento Open Source lub Adobe Commerce, musisz go zabezpieczyć NATYCHMIAST. Z tego artykułu dowiesz się, jak to zrobić.
Co się stało?
O sprawie jako pierwsza poinformował Sansec – holenderska firma zajmująca się bezpieczeństwem e-Commerce. I to jest istotny szczegół, bo jej zespół nie znalazł tej luki podczas rutynowego audytu. Znalazł ją, analizując sklepy, które ktoś już zaatakował.
Pierwszy potwierdzony atak miał miejsce 4 września. Pierwszy sklep, który przeanalizowała Sansec, miał komplet lipcowych i sierpniowych poprawek bezpieczeństwa oraz czysty status security:patch-status. To niestety nie wystarczyło. Sklep został zhakowany.
Dzień później, 5 września, Sansec opublikował ostrzeżenie (jeszcze przed ukończeniem własnej analizy technicznej). Uzasadnienie było krótkie: sklepy są przejmowane w tej chwili. Na tym etapie podatność nie miała jeszcze numeru CVE ani oficjalnej poprawki.
7 września Adobe wydało biuletyn APSB26-146. Podatność Style Smuggler otrzymała numer CVE-2026-75650, ocenę 10.0 w skali CVSS i priorytet 1, czyli najwyższy z możliwych. Adobe potwierdziło przy tym, że luka jest aktywnie wykorzystywana w atakach.
Tego samego dnia pojawiła się oficjalna poprawka, która wyszła jako hotfix, a nie jako pełne wydanie platformy. Oznacza to, że trzeba ją wdrożyć osobno. Samo zaktualizowanie Magento do najnowszej wersji nie rozwiąże problemu.
WAŻNE!
Ataki trwały przez kilka dni, zanim poprawka w ogóle powstała. Ma to poważne konsekwencje. Ale do tego wątku jeszcze wrócimy, bo ma on bezpośrednie przełożenie na to, co powinieneś zrobić ze swoim sklepem.
Jak działa Style Smuggler?
Atak Style Smugglera przebiega w dwóch etapach i cała jego elegancja polega na tym, że korzysta on wyłącznie z mechanizmów, które Magento ma wbudowane.
Etap 1: zatrucie pliku. Atakujący doprowadza do tego, że Magento samo zapisuje na dysku plik zawierający kod PHP. Może to być raport awarii w var/report/ albo wpis w var/log/system.log. Nic tu jeszcze nie zostaje uruchomione. Kod po prostu leży i czeka.
Etap 2: wykonanie. Atakujący wywołuje wbudowaną w Magento wiadomość „Payment Transaction Failed Reminder”, czyli przypomnienie o nieudanej transakcji płatniczej. Podczas renderowania szablonu tego maila zatruty kod zostaje uruchomiony.
I tutaj musisz zrozumieć dwie rzeczy.
Po pierwsze, nikt nie musi tego maila otworzyć – kod wykonuje się na etapie składania wiadomości, nie jej czytania.
Po drugie, atak działa nawet wtedy, gdy wysyłka maila w ogóle się nie powiedzie.
Złośliwy kod przemyca się do systemu szablonów przez właściwości styles (stąd nazwa tej luki) i dzięki temu omija istniejące zabezpieczenia. Adobe klasyfikuje to jako wstrzyknięcie kodu do szablonu po stronie serwera (ang. server-side template injection, CWE-1336).
Ocena 10.0 w skali CVSS nie bierze się znikąd. Atak nie wymaga logowania, nie wymaga żadnych uprawnień i nie wymaga, żeby ktokolwiek w niego kliknął. Wystarczy sieciowy dostęp do sklepu.
Cała sztuczka polega na tym, że atakujący nie musiał niczego łamać. Wystarczyło, że przekonał sklep, żeby zrobił to za niego.
Podatny, zaatakowany, wyciek danych – to trzy różne rzeczy
W komunikacji o incydentach bezpieczeństwa te trzy pojęcia notorycznie się zlewają, a różnica między nimi jest ogromna.
Sklep podatny to sklep, w którym luka występuje i teoretycznie może zostać wykorzystana. Nic więcej. Jeśli masz Magento w podatnej wersji i nie nałożyłeś poprawki, jesteś w tej kategorii (razem z dziesiątkami tysięcy innych sklepów).
Sklep zaatakowany to sklep, w którym znaleziono ślady wskazujące na skuteczne wykorzystanie podatności albo na obecność atakującego w środowisku. Podejrzany proces, wpis w cronie, którego nikt nie dodawał, charakterystyczny ślad w logach to właśnie ten stan.
Wyciek danych oznacza, że dane zostały faktycznie odczytane i przekazane poza środowisko sklepu.
Te stany nie przechodzą w siebie automatycznie. Samo występowanie podatności nie oznacza, że sklep został zaatakowany. Wykrycie śladów włamania nie oznacza automatycznie, że doszło do wycieku danych.
Działa to też w drugą stronę i tu trzeba być uczciwym: skuteczne wykorzystanie Style Smugglera pozwala uruchomić kod z uprawnieniami aplikacji Magento. Czyli atakujący mógł sięgnąć po wszystko, do czego dostęp ma sama aplikacja – konfigurację sklepu, dane dostępowe do bazy, dane klientów i zamówień, tokeny i sekrety integracji. Przy potwierdzonym statusie “zaatakowany rozsądnie jest przyjąć ostrożne założenie, że te dane mogły wyciec poza Twój sklep.
Czy Twój sklep jest podatny?
Jeśli Twój e-Commerce działa na:
- Adobe Commerce 2.4.4-2026-aug do 2.4.9-2026-aug i wersje wcześniejsze
- Magento Open Source 2.4.6-2026-aug do 2.4.9-2026-aug i wersje wcześniejsze
- Adobe Commerce B2B 1.3.3 do 1.5.3 i wersje wcześniejsze
to TAK. Taką listę wersji podaje Adobe w biuletynie APSB26-146.
W praktyce oznacza to, że luka Style Smuggler dotyczy niemal każdego sklepu na Magento.
I tu dochodzimy do rzeczy, która w tej całej sprawie jest najbardziej niewygodna. Bycie na bieżąco z aktualizacjami tym razem nikogo nie uchroniło. Pamiętasz sklep, który w którym Sansec znalazł tą lukę po raz pierwszy? Miał on wszystkie dostępne poprawki, a wbudowana kontrola statusu zwracała czysty wynik – żadnych problemów. Rzeczywistość była jednak zupełnie inna.
Nie oznacza to jednak, że regularne aktualizowanie Magento przestało mieć sens. Nadal jest to jedna z najważniejszych rzeczy, jakie możesz zrobić dla bezpieczeństwa swojego e-Commerce. Oznacza to jednak coś innego: w przypadku “nowej” podatności ta rada z definicji nie zadziała. Bo poprawki, którą miałbyś wdrożyć, po prostu jeszcze nie ma.
Zostaje więc jedno pytanie: co w takim razie powinieneś zrobić?
Co zrobić teraz
1. Zacznij od hotfixa
Adobe udostępniło już poprawkę VULN-39341-composer-patches.zip, możesz ją pobrać z repo.magento.com i nałożyć jako composer patch, zgodnie z instrukcją Adobe.
Jest jedno zastrzeżenie. Adobe przetestowało ten hotfix wyłącznie na wydaniach 2026-aug wymienionych w biuletynie. Na innych wersjach może zadziałać, ale nikt tego oficjalnie nie potwierdził. Zanim więc poprawka trafi na produkcję, sprawdź jej kompatybilność ze swoim sklepem i jego integracjami.
A jeśli z jakiegoś powodu nie możesz nałożyć jej od razu? Rozważ tymczasowe ograniczenie dostępu do GraphQL. Pamiętaj jednak, że to obejście problemu, a nie jego naprawa.
2. Sprawdź, czy poprawka faktycznie się nałożyła
Na oko tego nie stwierdzisz. Adobe rekomenduje weryfikację przez Quality Patches Tool:
vendor/bin/magento-patches -n status | grep „39341\|Status”
Status ma zwrócić Applied. Jeśli zwraca cokolwiek innego, poprawki nie ma i sklep nadal jest podatny na zagrożenie.
3. Wymień klucz szyfrujący i dane dostępowe
Adobe traktuje to jako część naprawy, nie jako opcjonalny dodatek. I słusznie, bo poprawka zamyka drzwi, ale nie zmienia zamka, jeśli ktoś zdążył już dorobić sobie klucz.
Kolejność jest następująca: włącz tryb serwisowy, wyłącz crona i wymień klucz szyfrujący. Potem po kolei zmień:
- hasła wszystkich użytkowników panelu administracyjnego,
- tokeny integracji REST/SOAP/GraphQL (System > Rozszerzenia > Integracje),
- sekrety OAuth aplikacji zewnętrznych,
- dane dostępowe do bramek płatniczych, i to u dostawcy: Stripe, Braintree, Adyen, PayPal,
- dane dostępowe do bazy,
- klucze SSH i deploy oraz konta usługowe crona,
- klucze API integracji kurierskich, podatkowych i pozostałych rozszerzeń.
Na koniec wyczyść cache, włącz crona i wyłącz tryb serwisowy.
PAMIĘTAJ!
Wymiana samego klucza szyfrującego nie unieważnia danych, które mogły już wyciec. Klucz szyfruje tokeny integracji i dane bramek płatniczych, ale jeśli atakujący zdążył je odczytać, ma je u siebie. I nie obchodzi go, jakim kluczem są zaszyfrowane w Twojej bazie. Dlatego zmieniasz je u źródła, a nie tylko wewnątrz Magento.
Poprawka to nie koniec
Nałożenie poprawki zamyka lukę. Ale nie cofa czasu.
Ataki ruszyły 4 września i trwają do dziś. Najpierw dlatego, że poprawki po prostu nie było. Potem dlatego, że wiele sklepów jeszcze jej nie nałożyło. I tu jest pies pogrzebany: nie liczy się data, w której Adobe wydało hotfix, tylko data, w której Ty go wdrożysz. Cały czas między 4 września a tym momentem to okno, w którym Twój sklep stoi otworem.
Hotfix od Adobe zamyka podatność. Nie usuwa jednak złośliwego oprogramowania, które być może siedzi już na Twoim serwerze.
Działa to też w drugą stronę. Usunięcie złośliwego oprogramowania z serwera nie zamyka podatności. Potrzebujesz obu tych działań. Nie jednego z nich.
Czego więc szukać?
- Podejrzanych procesów. Złośliwe oprogramowanie opisane przez Sansec ukrywa się pod nazwą [kworker/u:8:0]. Tak nazywa się jeden ze zwykłych procesów systemowych Linuksa, więc na liście procesów nic tu nie zwraca uwagi. Różnica jest jednak taka, że prawdziwy proces systemowy o tej nazwie działa na koncie administratora serwera i nie zajmuje pamięci. Jeśli więc widzisz proces [kworker/u:8:0], który działa na koncie Twojego sklepu i zajmuje pamięć, to nie jest żaden proces systemowy. To intruz. Sprawdź przy okazji również procesy o nazwie fc-cache.
- Plików w nietypowych miejscach. Złośliwy plik lądował w katalogu domowym użytkownika (~/.local/share/.gvfsd/gvfsd-user), a nie w katalogu sklepu. Skanowanie samych plików sklepu go nie wykryje.
- Wpisów w cronie. Szukaj zadania, które co pięć minut uruchamia się ponownie i odwołuje się do .gvfsd/gvfsd-user.
- Śladów w logach. Sprawdź zarówno var/report/, jak i var/log/system.log. Potwierdzone infekcje przechodziły przez oba te miejsca. Szukaj wzorca X_TRACE_ oraz błędu TypeError związanego z funkcją array_merge().
- Nietypowego wysypu maili „Payment Transaction Failed Reminder”.
- Ruchu sieciowego do adresów wskazanych przez Sansec w ich komunikacie.
I tu musimy być z Tobą szczerzy, bo bez tego zastrzeżenia powyższa lista wprowadzałaby Cię w błąd.
Po pierwsze, część zainfekowanych serwerów w ogóle nie łączyła się z atakującymi. Cisza w ruchu sieciowym niczego więc nie przesądza.
Po drugie, złośliwy plik uruchomiony w pamięci potrafił różnić się od swojej wersji zapisanej na dysku. Narzędzia, które porównują pliki i wyłapują w nich zmiany, mogą go po prostu przeoczyć.
Po trzecie, ślad zostawiany w logach zmieniał się w trakcie kampanii. Szukanie jednego konkretnego ciągu znaków to za mało.
Do tego atakujący poprawiali swój kod po kilka razy dziennie.
Co z tego wynika? Brak powyższych wskaźników nie jest dowodem na to, że Twój sklep jest czysty. Jest tylko brakiem dowodu na to, że jest zainfekowany. A to spora różnica.
Znalazłeś ślady? Nie sprzątaj w pośpiechu
Odruch jest naturalny: skasować wpis w cronie, ubić proces, iść dalej. Tylko że w jednym z opisanych przypadków ten sam złośliwy wpis pojawił się 1728 razy i wracał w ciągu sekundy po usunięciu.
Sensowna kolejność wygląda więc inaczej.
Najpierw zabezpiecz dowody: logi, obraz systemu plików, listę procesów.
Dopiero potem zacznij czyścić.
Jeśli masz kopię zapasową sprzed 4 września, rozważ przywrócenie z niej środowiska. Wymień dane dostępowe zgodnie z listą z poprzedniej sekcji. Przejrzyj konta administratorów i aktywne integracje pod kątem zmian, których nikt nie zlecał. Przeanalizuj logi z okresu, w którym mogło dojść do ataku. I zostaw rozszerzony monitoring. Po sprzątaniu, nie zamiast niego.
Jeśli nie masz w zespole nikogo, kto zajmuje się analizą powłamaniową, to jest moment na zewnętrzne wsparcie. Niedokładnie posprzątany serwer to gorsza sytuacja niż serwer, o którym wiesz, że jest zainfekowany.
A co z RODO?
Jeśli na Twoim serwerze potwierdzono ślady włamania, sytuację trzeba ocenić również pod kątem naruszenia ochrony danych osobowych. Sklep na Magento przetwarza dane klientów i zamówień, a udany atak dawał dostęp do wszystkiego, co widzi aplikacja.
Ale uwaga, bo to ważne. Sam fakt zaatakowania serwera nie oznacza automatycznie wycieku danych ani naruszenia, które trzeba zgłosić. Przy ocenie powinieneś wziąć pod uwagę zakres potencjalnego dostępu, rodzaj przetwarzanych danych oraz to, co faktycznie wyszło z analizy incydentu.
Decyzja o zgłoszeniu należy do Administratora danych i powinna zapaść wspólnie z Inspektorem Ochrony Danych (jeśli go wyznaczyłeś) lub doradcą prawnym. Do jej podjęcia potrzebujesz konkretów: kiedy wykryto ślady, jakie dokładnie i jaki był potencjalny zakres dostępu. Tych informacji powinien dostarczyć Ci Twój dostawca hostingu albo partner techniczny (a’ka agencja e-Commerce).
Jak przygotować się na następny raz?
Style Smuggler nie będzie ostatnią krytyczną podatnością w Magento. I nie jest to zarzut wobec tej platformy e-Commerce. CosmicSting, SessionReaper i kilka innych nazw dobrze pokazują, że każdy popularny system sprzedażowy jest celem. Bo za każdym stoją pieniądze i dane kart płatniczych.
Co więc odróżnia sklep, który stracił kilka godzin, od sklepu, który o włamaniu dowiedział się od operatora płatności miesiąc później?
Kopie zapasowe, które faktycznie da się odtworzyć.
Nie takie, o których wiesz, że gdzieś są.
Monitoring plików i procesów, nie tylko dostępności sklepu.
W tym ataku dostępność nie spadła ani na chwilę. Sklepy działały. Sprzedawały. I jednocześnie były zainfekowane.
Ktoś, kto odbierze telefon w sobotę.
Ta luka wyszła na jaw w piątek wieczorem, a poprawka pojawiła się w poniedziałek wieczorem. Umowa serwisowa działająca od poniedziałku do piątku w godzinach 9-17 na niewiele się w takim scenariuszu przyda.
Ograniczenie uprawnień sklepu na serwerze.
Twój sklep do normalnej pracy nie potrzebuje wszystkiego, co serwer potrafi zrobić. Wyłączenie zbędnych funkcji systemowych, zabezpieczenie katalogów tymczasowych i ograniczenie zapisu w miejscach, w których złośliwe oprogramowanie mogłoby się ukryć i uruchomić ponownie, nie zastąpi poprawki. Ale mocno utrudnia zamianę pojedynczego ataku w trwałą obecność na Twoim serwerze.
Wiedza o tym, gdzie leżą Twoje klucze i tokeny.
Jeśli ich wymiana zajmuje trzy dni i wymaga archeologii w dokumentacji, to w kryzysie po prostu jej nie zrobisz.
Jak zareagowaliśmy w Satisfly?
Nie będziemy Ci tu opowiadać, jacy jesteśmy wspaniali. Opiszemy Ci po prostu, co robiliśmy przez ostatnie dni, bo to chyba najlepiej pokazuje, jak w praktyce wygląda reagowanie na tego typu zagrożenie.
Zaraz po ostrzeżeniu Sansec rozszerzyliśmy monitoring środowisk Magento o znane wskaźniki włamania związane ze Style Smugglerem. Sprawdzamy podejrzane procesy i pliki na serwerach, zadania cykliczne, które mogą ponownie uruchamiać złośliwe oprogramowanie, oraz charakterystyczne ślady zostawiane przez ten konkretny atak.
Monitoring działa niezależnie w dwóch systemach.
Zabbix regularnie skanuje serwery pod kątem znanych wskaźników i w razie wykrycia zagrożenia wysyła zespołowi alert o najwyższym priorytecie.
Wazuh stanowi drugą, niezależną warstwę bezpieczeństwa, działającą bezpośrednio na serwerze.
Po co dwa systemy? Bo pojedynczy monitoring, który po cichu przestanie działać, jest gorszy niż jego brak. Daje złudzenie kontroli. Dlatego pilnujemy również samego mechanizmu kontrolnego, żeby wychwycić moment, w którym przestanie on spełniać swoje zadanie.
Równolegle pracujemy nad dodatkowymi zabezpieczeniami serwerów Magento, czyli dokładnie tym, o czym pisaliśmy akapit wyżej. Przed wdrożeniem każdego z nich sprawdzamy jego kompatybilność z konkretnym sklepem i jego integracjami. Bo zabezpieczenie, które psuje działanie platformy, nie jest żadnym zabezpieczeniem.
I jedna rzecz na koniec. Jeśli prowadzisz sklep na Magento i nie wiesz, czy ktoś zajmuje się u Ciebie tymi sprawami, to jest dobry moment, żeby o to zapytać. Niezależnie od tego, kto jest Twoim partnerem technologicznym.
Podsumowanie
Style Smuggler to krytyczna i aktywnie wykorzystywana podatność, która pozwala uruchomić kod na serwerze Twojego sklepu bez logowania. Adobe wydało poprawkę 7 września i jej wdrożenie jest teraz najważniejszym działaniem. Ale samo w sobie nie wystarczy.
Zamknięcie luki chroni Cię przed kolejnym atakiem tą drogą. Nie mówi jednak nic o tym, czy ktoś nie wszedł wcześniej. Dlatego obok poprawki potrzebujesz sprawdzenia środowiska, a przy potwierdzonych śladach włamania – wymiany danych dostępowych i oceny incydentu pod kątem ochrony danych osobowych.
I jedna rzecz, którą warto z tej historii wyciągnąć na przyszłość. Aktualny sklep to nie to samo co sklep bezpieczny. Style Smuggler udowodnił to na sklepie, który miał wszystkie łatki i czysty status bezpieczeństwa.
Stan na 8 września 2026. Sytuacja rozwija się dynamicznie, więc przed podjęciem działań warto sprawdzić aktualną treść biuletynu Adobe.
