StyleSmuggler CVE-2026-75650: hotfix Adobe na RCE w Magento

Adobe 7 września 2026 opublikowało hotfix VULN-39341 na CVE-2026-75650, biuletyn APSB26-146. Ocena CVSS 10.0, priorytet 1. Luka, którą Sansec nazwał StyleSmuggler, pozwala wykonać kod na serwerze Magento Open Source i Adobe Commerce bez logowania. Ataki trwają od 4 września. Hotfix zamyka wektor. Nie usuwa implantu z trzech dni przed poprawką.

Źródła: analiza Sansec i komunikat Adobe. Ten wpis jest checklistą operatora: potwierdzenie hotfixu, skan IoC, rotacja klucza szyfrowania i sekretów u źródła.

Które wersje są podatne

Adobe wymienia Adobe Commerce 2.4.4 do 2.4.9, Magento Open Source 2.4.6 do 2.4.9 oraz Adobe Commerce B2B 1.3.3 do 1.5.3, w tym wydania 2026-aug i wcześniejsze w tych liniach. Sansec odtworzył łańcuch bez logowania na czystych instalacjach Magento Open Source 2.4.7, 2.4.8 i 2.4.9. Pierwsza znaleziona ofiara działała na 2.4.6-p15 z poprawkami z lipca i sierpnia 2026. Wynik security:patch-status był czysty. 7 września Shield zablokował sondę na 2.4.7-p10.

Aktualna wersja produktu bez VULN-39341 nie chroni. Przeniesienie sesji do Redis albo bazy też nie.

Adobe testowało hotfix na wydaniach 2026-aug. Starsze buildy w tych gałęziach są podatne. Zgodność patcha tam nie jest potwierdzona przez Adobe.

Jak wygląda łańcuch ataku

Luka siedzi w systemie szablonów. Właściwości styles pozwalają wprowadzić złośliwy kod PHP i ominąć istniejące zabezpieczenia. Sansec opisuje dwa etapy:

• Wstrzyknięcie kodu PHP, na przykład przez odpowiednio przygotowany raport błędu.
• Wykonanie tego kodu przy renderowaniu standardowej wiadomości Magento o nieudanej płatności.

W ruchu widać m.in. POST /graphql z parametrami styles oraz ścieżki związane z płatnością, w tym /paypal/transparent/response/. Atak celowo wywołuje mail „Payment Transaction Failed Reminder”. Kod wykonuje się przy generowaniu wiadomości. Nikt nie musi otworzyć maila. Atak może się udać także wtedy, gdy wysyłka maila się nie powiedzie.

Nagły wzrost takich maili to sygnał do sprawdzenia. Sam brak maili nie oznacza, że sklep jest czysty.

Co zostaje po udanym ataku

Po RCE na serwerze pojawia się implant w Rust. Łączy się z infrastrukturą C2 i czeka na polecenia. Sansec do 7 września nie potwierdził dalszego użycia implantu na ofiarach. Sam trwały dostęp już wystarczy, żeby traktować sprawę jak incydent.

Pierwszy wariant procesu udaje [kworker/u:8:0]. Od 6 września widać wariant fc-cache: kopia w ~/.cache/fontconfig/fc-cache, cron o minutach 13 i 43, komunikacja UDP na port 123 do domen wyglądających jak serwery czasu (ntp.timesync.to i podobne). 7 września ten sam implant na części hostów zmienił nazwę na chronyd i ścieżkę /tmp/.chrony-<8hex>/chronyd. To nie jest systemowy daemon NTP. Pusty crontab -l nie wystarcza, wpis bywa dopisywany wprost do pliku spool.

Ruch UDP/123 wygląda jak synchronizacja czasu. W pakietach są m.in. hostname, użytkownik, wersja systemu i zużycie zasobów.

7 września Sansec opisał też drugi, osobny wektor na tych samych ofiarach: krótki dropper PHP i webshell w cache obrazów produktów, pod ścieżką w stylu pub/media/catalog/product/cache/ss_<10hex>/sync_<10hex>.php. Usunięcie procesu w tle nie kończy sprawy. W mediach nie powinno być plików PHP.

Co zrobić teraz

Kolejność z komunikatu Adobe i skanu pod kątem kompromitacji. Patch nie zastępuje skanu. Skan nie zastępuje patcha.

1. Hotfix VULN-39341. Pobierz VULN-39341-composer-patches.zip z repo.magento.com i nałóż jako composer patch, według wersji z tabeli Adobe. Potwierdź status:

vendor/bin/magento-patches -n status | grep "39341\|Status"

Szukasz statusu Applied przy VULN-39341. Sam numer Magento albo zielony security:patch-status z sierpnia tego nie pokazuje.

2. Skan IoC. Na hoście Magento możesz odpalić nasz skrypt (bez exploita, tylko sygnały z analizy Sansec, w tym chronyd w /tmp i PHP w pub/media):

curl -fsSL https://opselis.pl/scripts/stylesmuggler-check.sh -o stylesmuggler-check.sh
chmod +x stylesmuggler-check.sh
./stylesmuggler-check.sh /sciezka/do/magento

Albo ręcznie:

crontab -l | grep -iE 'gvfsd|fc-cache|chronyd'
ls -la ~/.local/share/.gvfsd/ ~/.cache/fontconfig/fc-cache /tmp/.kw_* /tmp/.cache_* /tmp/.gvfsd-* /tmp/.fc-*/fc-cache /tmp/fc-cache /tmp/.chrony-*/chronyd 2>/dev/null
ps -eo pid,comm,args | grep -E '\[kworker/u:8:0\]|/tmp/.chrony|fontconfig/fc-cache'
grep -ril 'x_trace_' var/report/
find pub/media -name '*.php'

Sprawdź też ruch wychodzący UDP/123 z serwera aplikacji oraz IoC z analizy Sansec: domeny NTP-kształtne, adresy C2, ścieżki w /tmp, cron i procesy [kworker/u:8:0], fc-cache oraz chronyd spoza systemu.

3. Rotacja po patchu. Adobe każe: tryb konserwacji, wyłączenie crona, rotacja klucza szyfrowania Magento, potem sekrety u źródła, nie tylko w panelu. Klucz szyfruje tokeny integracji, dane bramek i tokeny automatyzacji. Sama zmiana klucza nie unieważnia kopii, którą atakujący już odczytał.

Rotujesz: hasła administratorów, tokeny REST/SOAP/GraphQL, sekrety OAuth, klucze API bramek płatności, hasło bazy, klucze SSH i deploy, klucze rozszerzeń. Potem flush cache, włączenie crona, wyłączenie trybu konserwacji.

4. Jeśli znajdziesz implant. Traktuj to jak incydent: izolacja, hotfix jeśli jeszcze nie ma, rotacja jak wyżej, przegląd crona (także pliku spool, nie tylko crontab -l), mediów, raportów i logów od 4 września, ustalenie zakresu dostępu. Zabicie jednego procesu nie usuwa persistence.

Tymczasowe wyłączenie GraphQL było mitygacją przed hotfixem. Po VULN-39341 nie zastępuje skanu ani rotacji. WAF i Shield ograniczają wejście. Nie zastępują poprawki Magento.

Opieka warstw na sklepie: security. Utrzymanie Magento: ecommerce.

W skrócie: StyleSmuggler to CVE-2026-75650, RCE bez logowania, hotfix Adobe VULN-39341 od 7 września 2026. Najpierw hotfix i skan pod kątem implantu. Potem rotacja klucza i sekretów u źródła.