News
StyleSmuggler: zero-day-ul Magento exploatat activ și ce ai de făcut acum
7 septembrie 2026 - de Alexandru-Manuel Carabus
Există o vulnerabilitate Magento exploatată LIVE chiar acum. StyleSmuggler lovește Magento Open Source și Adobe Commerce curente, versiunile 2.4.7 până la 2.4.9, nu are nevoie de autentificare, iar atacurile au început în weekendul de 4 septembrie. Iată ce este, cine e afectat și exact ce ai de făcut acum.

Există o vulnerabilitate Magento exploatată în sălbăticie chiar acum și, dacă rulezi un magazin, nu ar trebui să aștepți până luni ca să te ocupi de ea. Se numește StyleSmuggler, a fost descoperită de cercetătorii de la Sansec, afectează versiunile curente de Magento Open Source și Adobe Commerce și nu are nevoie de autentificare și nici de vreo acțiune a victimei ca să ruleze cod pe serverul tău. Atacurile au început în weekendul de 4 septembrie 2026. Iată ce este, cine e afectat și exact ce ai de făcut acum.
Actualizare, 22 septembrie 2026. Articolul a fost publicat cât timp StyleSmuggler era încă un zero-day fără patch. Între timp Adobe a livrat un hotfix de urgență, vulnerabilitatea este înregistrată ca CVE-2026-75650 cu scor CVSS 10.0, iar CISA a adăugat-o pe 8 septembrie în catalogul de vulnerabilități exploatate cunoscute. Intervalul de versiuni afectate este și el considerabil mai larg decât se știa în ziua publicării. Secțiunile de mai jos au fost corectate. Dacă nu ai aplicat încă hotfixul, fă asta înainte să citești restul.
Ce este StyleSmuggler
În termeni simpli, StyleSmuggler strecoară cod malițios prin sistemul de template-uri al Magento, ascunzându-l în proprietăți legate de stil într-un fel care trece de protecțiile existente ale platformei. Codul injectat se execută apoi când Magento randează un anumit email de sistem, memento-ul de tranzacție de plată eșuată. Partea periculoasă e combinația: un atacator nu are nevoie să fie autentificat, iar victima nu are nevoie să dea click pe nimic. Asta transformă o ciudățenie de template în cod rulat pe serverul tău. Nu publicăm intenționat cum, la fel cum nu au făcut-o nici cercetătorii; ce le trebuie proprietarilor de magazine e forma riscului și răspunsul.
Cine e afectat și de ce upgrade-ul nu te salvează
Asta e partea care doare și se întinde mult mai departe de cea mai nouă versiune. Adobe listează Adobe Commerce de la 2.4.4 până la 2.4.9 inclusiv, Magento Open Source de la 2.4.6 la 2.4.9 și Adobe Commerce B2B de la 1.3.3 la 1.5.3. Tratează orice magazin pe 2.4 ca afectat până nu ai verificat. Sansec a documentat o victimă care rula 2.4.6-p15 cu patch-urile de securitate din iulie și august 2026 aplicate, așa că nici faptul că erai complet patchuit până în luna precedentă nu a protejat aceste magazine. Când au început atacurile nu exista niciun fix în nicio versiune. A fost un zero-day autentic.
E exploatată chiar acum
Nu a fost niciodată un aviz teoretic. Sansec a observat atacuri live începând târziu, vineri 4 septembrie 2026, cu trei zile înainte să existe vreo remediere. Momentul nu e o întâmplare. Atacatorii lansează vineri noaptea și în weekenduri tocmai pentru că atunci magazinele sunt cel mai puțin supravegheate și cel mai lente la răspuns. Adobe nu a așteptat lansarea programată: a publicat buletinul APSB26-146 în afara calendarului, luni 7 septembrie seara, la 20:20 UTC, cu prioritate 1, cea mai mare. CISA a adăugat CVE-ul a doua zi în catalogul de vulnerabilități exploatate cunoscute și a dat agențiilor federale termen până pe 11 septembrie, ceea ce spune destul despre cum a fost evaluat și în afara Adobe.
Ce ai de făcut acum
Tratează asta ca pe un incident activ, nu ca pe un tichet de mentenanță. În ordine:
- Aplică hotfixul. Remedierea vine ca hotfix, nu ca o versiune completă. Descarcă VULN-39341-composer-patches.zip de pe repo.magento.com și aplică-l ca patch de composer, apoi confirmă că a intrat rulând vendor/bin/magento-patches -n status și căutând 39341 în rezultat. Testează întâi pe staging, ca remedierea în sine să nu îți strice checkout-ul.
- Restricționează GraphQL. Mitigarea recomandată de Sansec e să blochezi endpoint-ul GraphQL al Magento la nivel de server web sau firewall dacă magazinul tău nu îl folosește. Majoritatea vitrinelor clasice, non-headless, nu au nevoie de el expus. Dacă rulezi un magazin headless sau PWA care depinde de GraphQL, nu îl poți pur și simplu opri, așa că blochează-l cu reguli și supraveghează-l îndeaproape.
- Scanează pentru compromitere. Verifică-ți magazinul față de indicatorii de compromitere publicați de Sansec și scanează-ți baza de cod și baza de date pentru cod injectat și backdoor-uri. Pe magazinele compromise Sansec a găsit un backdoor scris în Rust și shell-uri PHP în directoarele de media, cu procesele malițioase rulând sub nume banale precum kworker, fc-cache și chronyd. Dacă magazinul tău a fost accesibil în weekendul de 4 septembrie, presupune că a fost sondat.
- Rotește cheia de criptare, nu doar parolele. Adobe spune explicit că hotfixul singur nu e suficient. Rotește cheia de criptare Magento și tot ce protejează ea: parolele de admin, token-urile de integrare REST, SOAP și GraphQL, secretele de client OAuth, credențialele API ale procesatorilor de plăți, credențialele bazei de date și cheile SSH și de deploy. Dacă ceva pare în neregulă, izolează magazinul, curăță-l și restaurează dintr-un backup cunoscut ca fiind curat, în loc să speri că ai eliminat tot.
De ce au fost prinse chiar și magazinele la zi
E al doilea eveniment de securitate Magento dureros într-un interval scurt, după SessionReaper, iar lecția e aceeași, care merită repetată pentru că rămâne adevărată. A deține un magazin auto-găzduit înseamnă a-i deține securitatea, iar securitatea nu e un upgrade de o singură dată pe care îl termini. E patchuire rapidă, monitorizare pentru atacurile care ajung înaintea patch-ului și cineva care chiar supraveghează în vinerea noaptea în care aterizează atacul. Un magazin pe care nu îl supraveghează nimeni e magazinul care e găsit primul. Am scris versiunea evergreen a acestui lucru în checklist-ul de securitate Magento și am spus povestea SessionReaper în materialul despre SessionReaper.
Cum ne ocupăm noi pentru magazinele pe care le rulăm
Pentru magazinele pe care le menținem, un eveniment ca acesta e exact rostul relației. Urmărim avizele de securitate ca să nu fie nevoie tu, punem la punct mitigările recomandate și aplicăm patch-ul de vendor în momentul în care e disponibil și validat, testat întâi pe staging ca un fix grăbit să nu îți dărâme checkout-ul. Un răspuns rapid și prioritizat când ceva e cu adevărat critic e tot rostul mentenanței și valorează cel mai mult într-o săptămână ca aceasta. Am prezentat acea cadență în ghidul de mentenanță.
Dacă rulezi un magazin Magento și nu ești sigur dacă ești expus, dacă ai fost deja lovit sau cine va aplica patch-ul când apare, asta e o discuție de avut azi, nu săptămâna viitoare. Programează un apel de strategie gratuit și verificăm unde te afli și ce urmează.