Adobe wydało 7 września awaryjną poprawkę na CVE-2026-75650 — podatność w Adobe Commerce, Adobe Commerce B2B i Magento Open Source z maksymalną możliwą oceną CVSS 10.0. Badacze z Sansec, którzy nadali jej nazwę StyleSmuggler, potwierdzili pierwsze udane ataki już 4 września, czyli trzy dni przed łatką. Luka pozwala na zdalne wykonanie kodu bez uwierzytelnienia, a pierwsza zidentyfikowana ofiara miała zainstalowane komplet lipcowych i sierpniowych aktualizacji bezpieczeństwa.
Jak działa atak
StyleSmuggler nie potrzebuje ani konta administratora, ani złośliwego rozszerzenia. Wykorzystuje mechanizm szablonów Magento, w którym dyrektywy pozwalają na dynamiczne podstawianie treści. Napastnik przemyca kod PHP przez właściwości styles, omijając w ten sposób istniejące zabezpieczenia filtrujące dyrektywy szablonów. Zatruty fragment ląduje w pliku, który Magento zapisuje w toku normalnej pracy.
Sam zapis nic jeszcze nie robi. Dopiero drugie żądanie uruchamia łańcuch przetwarzania szablonu, który dochodzi do skanera wstrzykiwania zależności — a ten wczytuje zatruty plik instrukcją include. W tym momencie kod napastnika wykonuje się na serwerze z uprawnieniami procesu PHP. Podatne są wszystkie wersje od 2.4.4 do 2.4.9 włącznie.
Co zostawiają po sobie napastnicy
W potwierdzonych przypadkach atakujący instalowali dwa rodzaje złośliwego oprogramowania. Pierwszy to backdoor napisany w Ruście, maskowany jako proces systemowy — pojawia się w liście procesów jako [kworker/u:8:0] albo fc-cache, a plik binarny bywa kopiowany do ~/.cache/fontconfig/fc-cache lub ~/.local/share/.gvfsd/gvfsd-user. Trwałość zapewnia mu wpis w cronie restartujący go co pięć minut. Starsze próbki komunikowały się z serwerem sterującym po TLS i WebSocketach, nowsze podszywają się ruchem pod protokół NTP, żeby wtopić się w normalny szum sieciowy.
Drugi element to niepozorny, 485-bajtowy dropper PHP, który zakłada webshella w katalogu z cache’em obrazków produktów. Wykonuje polecenia dopiero po podaniu właściwego nagłówka HTTP, więc przypadkowe wejście na ten plik nie zdradza niczego podejrzanego.
Dlaczego to sprawa dla każdego sklepu, nie tylko dla dużych
Magento to nie jest system, który stoi w izolacji. Serwer sklepu ma dostęp do bazy z zamówieniami, do poświadczeń bramki płatniczej, do tokenów integracji z hurtowniami i systemem magazynowym. Przejęcie go oznacza więc nie tylko możliwość podmiany strony, ale przede wszystkim dostęp do danych klientów i potencjalnie do podpięcia skimmera zbierającego numery kart przy kasie — a to klasyczny scenariusz kampanii Magecart, który na tej platformie powtarza się od lat.
Warto też zwrócić uwagę na okno czasowe. Sklepy, które działały między 4 a 7 września, nie mogą poprzestać na aktualizacji. Luka była wtedy wykorzystywana, a łatka usuwa podatność, nie usuwa natomiast backdoora, który już siedzi w systemie.
Co zrobić
Pierwszy krok to poprawka. Adobe udostępniło hotfix VULN-39341 (biuletyn APSB26-146, priorytet 1) — paczkę VULN-39341-composer-patches.zip z repo.magento.com nakłada się jako patch Composera.
Drugi krok to sprawdzenie, czy nie jest już za późno. Warto przejrzeć katalog pub/media pod kątem nieoczekiwanych plików PHP, poszukać w var/report/ znacznika X_TRACE_, sprawdzić procesy o nazwach kworker i fc-cache oraz przejrzeć crontab użytkownika, na którym działa PHP. Sygnałem ostrzegawczym bywa też nagła fala maili typu „Payment Transaction Failed Reminder” wychodzących ze sklepu.
Trzeci krok, najczęściej pomijany, to rotacja sekretów. Adobe zaleca wymianę klucza szyfrującego i wszystkiego, co ten klucz chronił: haseł administratorów, tokenów integracji REST, SOAP i GraphQL, sekretów OAuth, kluczy API do bramek płatniczych, poświadczeń bazy danych, kluczy SSH i deploy keys oraz kluczy API rozszerzeń firm trzecich. Jeśli sklep był wystawiony w krytycznym oknie, należy założyć, że wszystkie te dane wyciekły.
Na przyszłość: WAF przed sklepem, ograniczenie panelu administracyjnego do konkretnych adresów IP i monitorowanie zmian w plikach na serwerze nie zastąpią łatania, ale kupują czas w takich sytuacjach jak ta — kiedy exploit krąży wcześniej niż poprawka.
Podsumowanie
CVE-2026-75650 to przypadek, w którym nawet regularne aktualizowanie systemu nie wystarczyło, bo atak wyprzedził producenta o trzy dni. Dla właściciela sklepu na Magento oznacza to konkretne zadanie na najbliższe godziny: nałożyć hotfix, przeszukać serwer pod kątem śladów włamania i wymienić poświadczenia. Odłożenie tego „na po sezonie” jest w tym przypadku równoznaczne z pozostawieniem komuś otwartych drzwi do bazy klientów.