Sklepy na Magento włamane mimo kompletu łatek. Sam hotfix już nie wystarczy

Prowadzę sklep internetowy od dwudziestu lat i nauczyłem się, że najgorsze awarie to nie te, które widać na wykresie sprzedaży. W nocy z 4 na 5 września ktoś wszedł na serwery sklepów opartych na Magento, które miały wgrane wszystkie dostępne w tym momencie poprawki — a Adobe wydało łatkę dopiero trzy dni później. Pokazuję, co dokładnie zrobić w takim sklepie w tym tygodniu i dlaczego ta historia dotyczy też Ciebie, jeśli stoisz na PrestaShop albo WooCommerce.

Co się stało i dlaczego ocena 10.0 nie jest przesadą

Podatność ma numer CVE-2026-75650, a firma Sansec, która ją wykryła, nazwała ją StyleSmuggler. To nieuwierzytelnione wykonanie kodu: atakujący nie potrzebuje konta, hasła ani żadnego uprawnienia w sklepie. Stąd ocena CVSS 10.0 i priorytet 1 w klasyfikacji Adobe — wyżej się nie da.

Mechanizm jest dwuetapowy. Najpierw wstrzyknięcie kodu przez właściwości styles w silniku szablonów, potem wykonanie tego kodu w momencie, gdy Magento renderuje powiadomienie o nieudanej płatności. Napastnik sam wywołuje to powiadomienie, więc nie musi czekać, aż w sklepie coś się zepsuje.

Zasięg z komunikatu Adobe: Adobe Commerce 2.4.4 do 2.4.9, Adobe Commerce B2B 1.3.3 do 1.5.3 i Magento Open Source 2.4.4 do 2.4.9. Adobe pisze wprost, że podatność jest wykorzystywana w atakach na sklepy — to nie jest ostrzeżenie prewencyjne, tylko relacja z pola.

Trzy dni, w których nie było czego wgrać

Sansec datuje pierwsze potwierdzone wykorzystanie na 4 września, godzina 22:20 UTC. Hotfix VULN-39341 pojawił się 7 września o 20:20 UTC. Między jednym a drugim jest siedemdziesiąt godzin, w których żaden administrator nie mógł zrobić nic poza odcięciem sklepu albo pilnowaniem logów.

W tym oknie Sansec zaobserwował więcej niż jedną grupę. Jedna z prób nie powiodła się, a osiem sekund później druga weszła. Serwis BleepingComputer opisuje drugiego napastnika, który zostawił webshell w PHP o wielkości 485 bajtów, sprawdzał możliwość zapisu w katalogu pub/media i wyprowadzał dane przez subdomeny zewnętrznego serwisu. Backdoor maskował swój serwer sterujący jako zwykły serwer czasu NTP — ruch wychodzący wyglądał więc na najbardziej niewinną rzecz w całej infrastrukturze.

To jest sedno sprawy dla właściciela sklepu: sklepy, które ucierpiały, nie były zaniedbane. Miały wgrane wszystko, co istniało. Aktualność nie była w tym przypadku obroną, bo obrony jeszcze nie wyprodukowano.

Łatka to połowa roboty, a nie koniec

Adobe w tym samym komunikacie wymienia kroki, które trzeba wykonać po wgraniu hotfixa: wymiana klucza szyfrowania, zmiana haseł użytkowników panelu administracyjnego, regeneracja tokenów integracji, rotacja poświadczeń API, kluczy SSH i danych logowania do bazy. Logika jest prosta: jeśli ktoś wykonał kod na Twoim serwerze, to wyniósł z niego wszystko, co serwer wiedział. Zamknięcie drzwi nie odbiera mu kopii kluczy.

I tu zaczyna się część, o której nikt nie pisze w biuletynach bezpieczeństwa. Rotacja kluczy w sklepie z 15 tysiącami użytkowników miesięcznie to nie jedna komenda, tylko lista integracji, z których każda zaraz przestanie działać:

• feed produktowy do Merchant Center i do porównywarek,
• integracja z systemem magazynowym i księgowością,
• tokeny operatora płatności i bramki zwrotów,
• API firm kurierskich i generowanie etykiet,
• konektory analityczne, w tym wysyłka zdarzeń po stronie serwera,
• konta pracowników i wszystkie klucze w narzędziach zewnętrznych.

Zanim ruszysz pierwszy klucz, wypisz tę listę. Rotacja bez listy oznacza, że w piątek po południu sklep przestaje wysyłać zamówienia do magazynu, a Ty szukasz przyczyny w zupełnie innym miejscu.

Jak sprawdzić, czy ktoś już był

Najprostszy sygnał jest darmowy i nie wymaga żadnego narzędzia: e-maile „Payment Transaction Failed Reminder” wysyłane bez powodu. Atak celowo wywołuje to powiadomienie, więc nagły wysyp takich wiadomości w skrzynce sklepu albo w logu poczty jest realnym śladem. Poza tym:

• procesy o nazwach udających systemowe: chronyd, fc-cache, [kworker/u:8:0],
• pliki PHP w katalogu pub/media, gdzie żaden plik wykonywalny nie ma prawa być,
• ruch wychodzący do „serwera NTP”, którego nie ma w Twojej konfiguracji,
• zmiany w plikach rdzenia — porównanie sumy kontrolnej z czystą instalacją tej samej wersji.

Sansec udostępnia własny skaner integralności plików. Jeśli masz podejrzenie, że sklep był otwarty w tym oknie, samo wgranie hotfixa niczego nie potwierdzi ani nie wykluczy — trzeba przejść przez ślady.

Co z tego ma sklep na PrestaShop albo WooCommerce

Nie chodzi o Magento. Chodzi o czas reakcji, który każdy sklep ma zmierzony albo nie ma.

Zadaj sobie cztery pytania i zapisz odpowiedzi liczbami. Ile godzin od wydania poprawki krytycznej mija u Ciebie do wgrania jej na produkcję? Kiedy ostatni raz odtwarzałeś kopię zapasową na czystym środowisku, a nie tylko sprawdzałeś, że plik z kopią istnieje? Ilu ludzi ma dziś dostęp do panelu i ile z tych kont należy do osób, które już z Tobą nie pracują? Ile aktywnych tokenów API wisi w sklepie i kto je wystawił?

Druga rzecz to kolejki. Wielu sprzedawców zamraża zmiany przed Q4 i słusznie, bo listopad to nie czas na migrację. Ale zamrożenie zmian nie może obejmować poprawek bezpieczeństwa — to są dwie osobne kolejki i osobne procedury. Jeśli Twój wykonawca traktuje je tak samo, ustal to teraz, a nie 20 listopada.

Trzecia rzecz jest marketingowa i finansowa. Przejęty sklep to najczęściej skimmer w kasie, czyli podmieniony formularz płatności, który zbiera dane kart. Wtedy dochodzi zgłoszenie naruszenia do organu nadzorczego w ciągu 72 godzin, którego wymaga art. 33 RODO, zawiadomienie klientów, rozmowa z operatorem płatności i realne ryzyko, że stracisz przyjmowanie kart w środku sezonu. Do tego dane w analityce przestają być wiarygodne, bo część transakcji jest fałszywa albo nie dochodzi do systemu. Koszt liczy się wtedy nie w roboczogodzinach, tylko w wyłączonych kampaniach.

Co zrobić w najbliższym tygodniu

1. Ustal wersję: bin/magento --version. Jeśli mieści się w przedziale 2.4.4–2.4.9 (albo Adobe Commerce B2B 1.3.3–1.5.3), traktuj sklep jako podatny do czasu potwierdzenia łatki.
2. Wgraj hotfix VULN-39341 jako poprawkę Composera i potwierdź jego status, zamiast wierzyć, że „wykonawca wgrał”.
3. Przejrzyj ślady włamania z listy wyżej — zanim uznasz temat za zamknięty. Kolejność ma znaczenie: najpierw łatka, potem dowody.
4. Wypisz wszystkie integracje i konta, dopiero potem rotuj klucz szyfrowania, hasła administratorów, tokeny i poświadczenia API. Zaplanuj to na poniedziałek rano, nie na piątek.
5. Sklepy na starszych gałęziach 2.2 i 2.3 nie dostaną oficjalnej poprawki. Jeśli tam jesteś, decyzja o aktualizacji przestaje być kwestią budżetu na przyszły rok.
6. Nie stoisz na Magento? Zmierz swój czas od wydania poprawki do wdrożenia, na własnym przykładzie z ostatnich trzech miesięcy. Liczba w godzinach, nie w słowie „szybko”.
7. Rozdziel z wykonawcą kolejkę zmian i kolejkę bezpieczeństwa na czas zamrożenia przed Q4. Na piśmie, z czasem reakcji.

Zamiast obaw wolę prewencję: koszt przygotowania takiej listy to jedno popołudnie, a koszt jej braku poznaje się dokładnie wtedy, kiedy najmniej można sobie na niego pozwolić. Jeśli chcesz, żeby ktoś przeszedł z Tobą przez integracje i plan rotacji, zanim ruszysz klucze, umów się na konsultację.