StyleSmuggler și cele mai recente atacuri asupra magazinelor Magento: cum acționează hackerii și cum limitați riscul

7 septembrie 2026 9 min de citire 2 vizualizări

Ultimele zile au arătat un lucru pe care administratorii magazinelor online îl știu de mult timp, dar care este ușor de ignorat în mentenanța de zi cu zi: un sistem actualizat nu înseamnă întotdeauna un sistem sigur. Când apare o vulnerabilitate de tip 0-day, atacatorii nu așteaptă comunicatul oficial al producătorului, un număr CVE ordonat și un termen convenabil pentru implementarea patch-ului. Boții scanează internetul, caută endpointuri vulnerabile și încearcă să instaleze acces persistent mai repede decât reușesc majoritatea companiilor să convoace o ședință.

Exact așa arată cazul StyleSmuggler, adică o vulnerabilitate exploatată activ, raportată de Sansec la 5 septembrie 2026. Potrivit Sansec, atacurile au început pe 4 septembrie și vizează Magento Open Source și Adobe Commerce. Cea mai importantă informație pentru proprietarii de magazine sună dur: vulnerabilitatea a fost observată și pe instalări considerate complet actualizate.

Acest text nu este o instrucțiune de atac. Este un rezumat practic al modului în care arată astăzi o compromitere a unui magazin e-commerce și al măsurilor care pot fi luate aici și acum, înainte ca patch-ul oficial al producătorului să apară sau să fie confirmat.

Ce s-a întâmplat?

StyleSmuggler este descris ca un RCE neautorizat, adică posibilitatea de a executa cod pe server fără autentificare în panoul de administrare. Pe scurt: atacatorul nu are nevoie de parola administratorului, de un cont de angajat compromis sau de acces SSH. Este suficientă o aplicație vulnerabilă expusă la internet.

Potrivit analizelor publice, atacul are mai multe etape:

Atacatorul trimite o cerere special pregătită către Magento, folosind endpointul GraphQL.
Codul malițios ajunge într-un loc pe care Magento îl procesează ulterior automat.
Aplicația execută codul în cadrul mecanismului standard de gestionare a e-mailurilor, inclusiv în scenariul unei erori de plată.
Pe server este instalat un backdoor, adică un mecanism persistent de revenire.

Acesta este un model deosebit de periculos, deoarece nu necesită ca un angajat să acceseze un link și nici o autentificare reușită. Magazinul poate fi atacat doar pentru că este disponibil public.

Cum acționează hackerii astăzi?

Compromiterile magazinelor online seamănă din ce în ce mai rar cu un proces manual de 'hacking' asupra unei singure ținte. Mai des, acestea arată ca o campanie automatizată:

scanarea internetului în căutarea unui endpoint concret,
trimiterea unor încercări pregătite de exploatare a vulnerabilității,
instalarea unui proces care se prezintă drept un element legitim al sistemului,
menținerea accesului prin cron sau printr-un alt mecanism de autostart,
colectarea sesiunilor, secretelor, cheilor API sau datelor de plată,
eventuala instalare suplimentară a unui webshell, skimmer sau a unui alt backdoor.

În cazul StyleSmuggler, două detalii sunt deosebit de importante. În primul rând, backdoor-ul se poate afla în afara directorului magazinului, astfel că o simplă verificare a fișierelor Magento nu este suficientă. În al doilea rând, procesul poate imita un element de sistem, de exemplu printr-un nume asemănător cu kworker, fc-cache sau chronyd. Pentru un ochi neexperimentat pare inofensiv, dar faptul că rulează sub utilizatorul web ar trebui să aprindă un semnal de alarmă.

De ce nu este suficient doar nivelul de patch?

În cazul unei vulnerabilități obișnuite, răspunsul este simplu: verificăm versiunea, actualizăm, închidem subiectul. În cazul unui 0-day, situația este diferită. Pentru o anumită perioadă, vulnerabilitatea este exploatată înainte ca producătorul să publice patch-ul sau înainte ca patch-ul să fie corelat clar cu un atac concret.

De aceea, după un astfel de incident trebuie separate două întrebări:

magazinul este în continuare vulnerabil?
magazinul a fost deja compromis anterior?

Nu este același lucru. WAF, blocarea GraphQL sau un patch aplicat ulterior pot limita încercările următoare, dar nu elimină automat un backdoor care ar fi putut fi instalat mai devreme.

Ce trebuie făcut imediat?

1. Limitați temporar sau dezactivați GraphQL

Dacă magazinul nu folosește GraphQL, cea mai simplă decizie este blocarea temporară a /graphql până la confirmarea patch-ului. Multe magazine Magento clasice, inclusiv numeroase implementări bazate pe Hyvä, nu au nevoie de GraphQL public pentru funcționarea frontendului. Situația este diferită în magazinele headless și PWA - acolo blocarea poate opri vânzările, deci trebuie aplicate reguli WAF mai precise sau limitări ale traficului.

Exemplu de direcție pentru nginx:

map $uri $gql_block { default 0; ~*^/+(index\.php/+)?graphql(\.php)?(/|$) 1;}

În fiecare vhost Magento, înaintea celorlalte location:

if ($gql_block) { return 403;}

După modificarea configurației:

nginx -t && systemctl reload nginx

Dacă în fața magazinului rulează Varnish, merită curățat suplimentar cache-ul:

varnishadm ban 'req.url ~ .'

După implementare trebuie verificate diferite variante ale căii, nu doar forma ideală /graphql. Testul ar trebui să includă, printre altele, /graphql, /GraphQL, /graphql/, /graphql.php, /index.php/graphql și variante cu slash-uri duble. Rezultatul așteptat pentru GraphQL este 403, iar pentru pagina principală a magazinului un răspuns normal, de exemplu 200.

2. Blocați vectorul cunoscut `styles[...]`

Dacă nu puteți dezactiva întregul GraphQL, aplicați cel puțin reguli care blochează parametrul observat styles[...] în query string, precum și tiparele post-exploatare cunoscute.

Pentru nginx se pot folosi reguli în această direcție:

if ($query_string ~* 'styles(\[|%5[bB])') { return 403;}if ($request_uri ~* '/paypal/transparent/response/.*(eval|base64_decode|%3[cC]%3[fF])') { return 403;}if ($request_uri ~* '%3[cC]%3[fF]|<\?') { return 403;}

Pentru Apache, un mecanism analog poate fi bazat pe mod_rewrite, blocând aparițiile brute și codificate ale styles[, precum și încercările de a strecura un tag PHP în URL.

O precizare importantă: astfel de reguli văd URL-ul și query string-ul. Dacă o variantă a atacului mută payload-ul integral în body-ul cererii POST, simpla regulă a serverului web poate să nu fie suficientă. În acest caz este necesar un WAF care analizează body-ul, ModSecurity, o soluție de tip Sansec Shield sau dezactivarea temporară a GraphQL.

3. Verificați dacă magazinul nu a fost deja compromis

Blocarea încercărilor ulterioare este doar jumătate din muncă. Cealaltă jumătate constă în verificarea urmelor pe care atacul le-ar fi putut lăsa.

Rulați verificarea ca utilizatorul de sistem Magento:

crontab -l | grep -i gvfsdls -la ~/.local/share/.gvfsd/ ~/.cache/fontconfig/fc-cache /tmp/.kw_* /tmp/.cache_* /tmp/.gvfsd-* /tmp/.fc-*/fc-cache /tmp/fc-cache 2>/dev/nullps -eo pid,comm,args | grep -iE 'kworker|fc-cache|chronyd'grep -ril 'x_trace_' var/report/

Acordați atenție în special:

fișierelor din ~/.local/share/.gvfsd/,
fișierelor fc-cache în locații neobișnuite,
directoarelor temporare de tip /tmp/.kw_*, /tmp/.cache_*, /tmp/.fc-*,
intrărilor cron rulate la fiecare câteva minute,
proceselor care imită procese de sistem, dar rulează ca utilizator al magazinului,
fișierelor PHP din pub/media, unde în mod normal nu ar trebui să existe.

Exemplu de verificare rapidă pentru webshell-uri:

find pub/media -name '*.php' -print

Dacă rezultatul nu este gol, situația trebuie tratată ca un incident, nu ca o anomalie cosmetică.

4. Verificați logurile de acces

În loguri, căutați încercări care vizează GraphQL și cereri neobișnuite către căi de plată. Simpla prezență a unei cereri suspecte nu înseamnă întotdeauna o compromitere reușită, dar arată că magazinul a fost o țintă.

În practică, merită verificate:

cererile POST către /graphql cu parametri neobișnuiți,
aparițiile styles[ și ale formei codificate styles%5B,
cererile către /paypal/transparent/response/ cu fragmente suspecte,
serii bruște de cereri din multe adrese IP,
traficul din adrese cunoscute din IOC publice.

În materialele de lucru apar, printre altele, următoarele IOC: 185.157.160.251, 99.84.67.186, windwsecurity.run, ntp.timesync.to. Totuși, apărarea nu trebuie limitată doar la aceste valori. Potrivit descrierilor incidentelor, o parte din trafic provenea dintr-un pool mai mare de adrese și din infrastructură intermediară.

5. Mai întâi conservați dovezile, apoi curățați

Este o greșeală frecventă: administratorul vede un proces suspect, îl oprește, șterge fișierele și abia apoi începe analiza. În cazul unui backdoor bine scris, acest lucru poate distruge cele mai importante urme, iar uneori poate chiar îngreuna recuperarea probei.

Ordinea ar trebui să fie mai conservatoare:

Conservați logurile nginx/Apache, PHP-FPM, de sistem, Magento și cron.
Salvați lista proceselor, fișierelor deschise și conexiunilor de rețea.
Faceți o copie a fișierelor suspecte pentru analiză.
Eliminați intrările cron responsabile de recrearea procesului.
Abia apoi opriți procesele și eliminați mecanismele de persistență.
Forțați deconectarea sesiunilor utilizatorilor și administratorilor.
Rotiți secretele: crypt/key, parolele administratorilor, cheile API pentru plăți, integrări, SMTP, ERP, PIM și marketplace.

Dacă magazinul procesează plăți sau date ale clienților, după confirmarea compromiterii trebuie să tratați situația ca pe un incident de securitate complet, nu ca pe o simplă 'eliminare a unui virus'.

Câteva reguli care reduc efectiv riscul

Minimizați suprafața publică de atac

Endpointurile pe care magazinul nu le folosește nu ar trebui să fie disponibile public. Acest lucru se aplică pentru GraphQL, panouri de administrare, medii staging, domenii demo vechi și copii uitate ale magazinului. În e-commerce, foarte des nu producția este cea care cedează, ci un staging vechi cu o bază reală și aceleași secrete.

Separați mediile și permisiunile

Procesul Magento nu ar trebui să aibă mai mult acces decât are nevoie. Fără sudo, cont de sistem separat pentru fiecare magazin, separarea Redis, baze de date separate și comunicare outbound limitată pot transforma compromiterea unui magazin într-un incident limitat, în locul unei catastrofe pentru întreaga infrastructură.

Monitorizați procesele, cron și fișierele din afara webroot-ului

Scanarea doar a directorului Magento nu este suficientă. Backdoor-ul poate locui în directorul home al utilizatorului, în /tmp, în cache-ul fonturilor sau într-un alt loc accesibil procesului aplicației. Monitorizarea ar trebui să includă:

intrări cron noi,
procese neobișnuite sub utilizatorul web,
fișiere executabile noi în directoare temporare,
conexiuni către Redis, baze de date și internet,
modificări în app/etc/env.php,
conturi noi de administratori.

Actualizați, dar nu confundați actualizarea cu analiza incidentului

Când Adobe publică un patch, acesta trebuie implementat. Dar după un atac de tip 0-day, simpla implementare a patch-ului nu răspunde la întrebarea dacă cineva a fost deja în interior. De aceea, după patch trebuie efectuată în continuare verificarea IOC, a logurilor, sesiunilor și secretelor.

Pregătiți reguli de urgență gata de utilizare

Merită să aveți în repository sau în documentația operațională fragmente pregătite pentru nginx, Apache, Varnish și WAF. În criză nu există timp pentru scrierea regulilor de la zero. O bună practică este și testarea blocărilor pe staging, înainte ca acestea să fie necesare în producție.

Ce ar trebui să facă astăzi proprietarul magazinului?

Dacă folosiți Magento sau Adobe Commerce, faceți cel puțin următoarele:

Întocmiți o listă a tuturor instanțelor: producție, staging, demo, copii de lucru.
Verificați unde este GraphQL public și dacă este într-adevăr necesar.
Implementați o blocare temporară a GraphQL sau reguli care blochează styles[...].
Verificați blocarea prin teste HTTP.
Căutați pe server procese, cron, fișiere și loguri care indică StyleSmuggler.
Dacă găsiți IOC, conservați dovezile și tratați situația ca pe un incident.
După patch-ul oficial al producătorului, actualizați fiecare instanță, inclusiv staging și copiile vechi.
După actualizare, efectuați o nouă verificare și rotiți secretele dacă magazinul ar fi putut fi compromis.

Cea mai proastă decizie este să așteptați până când 'situația se clarifică'. În cazul unui 0-day exploatat activ, timpul lucrează în favoarea atacatorului. Chiar și o blocare temporară, dacă este bine testată și implementată conștient, poate câștiga ore prețioase.

Rezumat

StyleSmuggler este un bun exemplu de risc modern în e-commerce: atacul nu începe de la panoul de administrare, ci de la un endpoint public; nu se termină cu un singur fișier în directorul magazinului, ci cu un proces persistent în afara webroot-ului; iar un patch level actualizat nu oferă automat răspunsul la întrebarea dacă magazinul a fost sigur în fereastra de atac.

Apărarea trebuie să fie la fel de practică: limitați suprafața, blocați vectorul cunoscut, verificați compromiterea, conservați dovezile, rotiți secretele și abia apoi considerați subiectul sub control.

În astfel de situații nu câștigă cel care are cea mai frumoasă politică de securitate, ci cel care are proceduri pregătite, loguri, separarea mediilor și posibilitatea de a implementa rapid reguli de urgență fără a opri întreaga afacere.

Surse și materiale

Sansec: https://sansec.io/research/stylesmuggler-0day
The Hacker News: https://thehackernews.com/2026/09/unpatched-magento-and-adobe-commerce.html
Adobe Security Bulletin pentru Adobe Commerce: https://helpx.adobe.com/security/products/magento/apsb26-138.html