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

Aktualizacja 19 października 2026: 13 października Adobe wydało biuletyn APSB26-153 z kolejną krytyczną luką w silniku szablonów. Luka ma w rejestrze CVE (Common Vulnerabilities and Exposures) numer CVE-2026-103849 i ocenę 10.0 w skali CVSS (Common Vulnerability Scoring System). Adobe zaleca wgrać wrześniowy hotfix razem z nową aktualizacją bezpieczeństwa. Adobe nie zna przypadków wykorzystania tej luki (stan na 13 października). Przy okazji poprawiłem zakres podatnych wersji i opis drugiego napastnika.

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 pierwszej wersji ataku przy renderowaniu powiadomienia o nieudanej płatności, a w późniejszych wariantach bezpośrednio przez zapytanie GraphQL, bez żadnego e-maila. Napastnik sam wywołuje to powiadomienie, więc nie musi czekać, aż w sklepie coś się zepsuje.

Według komunikatu Adobe podatne są Adobe Commerce 2.4.4–2.4.9, Adobe Commerce B2B 1.3.3–1.5.3 i Magento Open Source 2.4.6–2.4.9 w wydaniach do sierpnia 2026 włącznie. Dla starszych gałęzi (2.2, 2.3 i 2.4.0–2.4.3), które nie mają już wsparcia, Adobe poprawki nie wydało, więc ich też nie traktuj jako bezpiecznych. 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 (czas uniwersalny koordynowany). Hotfix VULN-39341 pojawił się 7 września o 20:20 UTC. Między jednym a drugim jest siedemdziesiąt godzin, w których nie było oficjalnej poprawki; pozostawały odcięcie sklepu, pilnowanie logów i — od rana 5 września — reguły blokujące u dostawców zapór aplikacyjnych.

W tym oknie Sansec zaobserwował więcej niż jedną grupę. W jednym ze sklepów atak przez magazyn sesji się nie udał, ale ten sam napastnik osiem sekund później wszedł inną drogą — przez plik wgrany w opcjach produktu. Przeniesienie sesji do Redisa czy bazy nie chroni. Serwis BleepingComputer opisuje drugiego napastnika, który wgrywał 485-bajtowy skrypt PHP zapisujący webshell w katalogu pamięci podręcznej zdjęć produktów, sprawdzał możliwość zapisu w katalogu pub/media i wyprowadzał dane przez subdomeny zewnętrznego serwisu. Pierwsza grupa instalowała z kolei backdoor, który udawał komunikację z serwerem czasu NTP (Network Time Protocol) i wysyłał pakiety UDP (User Datagram Protocol) na port 123 — ruch wychodzący wyglądał więc na najbardziej niewinną rzecz w całej infrastrukturze.

To jest sedno sprawy dla właściciela sklepu: pierwszy sklep opisany przez Sansec nie był zaniedbany: miał wgrane wszystkie łatki z lipca i sierpnia 2026. 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.

Adobe każe rotować te poświadczenia także u dostawców, ale nie pisze, co w Twoim sklepie przestanie wtedy działać. 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 (np. na kwotę zero bez pozycji zamówienia) jest powodem do sprawdzenia sklepu. Uwaga: brak takich e-maili niczego nie wyklucza — nowsze warianty ataku działają bez nich, a sklepy po łatce nadal mogą dostawać te powiadomienia. 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 skaner złośliwego oprogramowania (eComscan), który wykrywa ten backdoor. 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 często kończy ze skimmerem w kasie, czyli podmienionym formularzem płatności, który zbiera dane kart — Sansec znalazł taki skimmer w jednym ze sklepów zaatakowanych przez tę lukę. Wtedy dochodzi zgłoszenie naruszenia do organu nadzorczego w ciągu 72 godzin, którego wymaga art. 33 RODO (ogólnego rozporządzenia o ochronie danych), zawiadomienie klientów (art. 34 RODO, gdy naruszenie niesie wysokie ryzyko — przy danych kart zwykle tak), 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. Każdą wersję 2.4.9 lub starszą (oraz Adobe Commerce B2B 1.5.3 lub starszą) traktuj jako podatną do czasu potwierdzenia łatki; dla wersji starszych niż 2.4.4 Adobe poprawki nie wydało.
2. Wgraj hotfix VULN-39341 (plik właściwy dla Twojej wersji z tabeli Adobe) jako poprawkę Composera i potwierdź jego status, a następnie zainstaluj aktualizację bezpieczeństwa z 13 października 2026 (biuletyn APSB26-153, m.in. CVE-2026-103849, również CVSS 10.0; dla Magento Open Source biuletyn podaje wersje 2.4.7–2.4.9) — sam wrześniowy hotfix już nie wystarczy.
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. Zrób to zaraz po wgraniu łatki, w trybie konserwacji z wyłączonym cronem, tak jak opisuje Adobe. Spisanie integracji to godziny, nie dni.
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ę.