Pe 4 septembrie 2026, la ora 22:20 UTC, primul magazin compromis rula Magento complet actualizat. Patch-urile din iulie și august erau aplicate, iar scanarea de securitate arăta curat. Atacatorii au găsit totuși o poartă pe care nimeni nu o văzuse. Adobe a publicat fixul de urgență APSB26-146 abia pe 7 septembrie. Povestea celor trei zile dintre ele explică mai bine decât orice teorie ce înseamnă securitate Magento în 2026.
Patru septembrie, ora 22:20: prima victimă
Firma de securitate Sansec a prins campania în aceeași seară. La 22:40 UTC, echipa lor a descoperit implantul pe un magazin, iar la 23:10, alte sisteme nelegate semnalau același cod. În câteva ore, cercetătorii au reprodus lanțul complet pe instalații curate de Magento Open Source. Au testat versiunile 2.4.7, 2.4.8 și 2.4.9. Pe 5 septembrie au publicat analiza și au pus reguli de protecție în producție de la ora 07:15. Apoi, numele dat atacului, StyleSmuggler, a rămas în toate rapoartele din industrie.
Victima inițială merită detaliată, pentru că sparge o iluzie comodă. Magazinul rula versiunea 2.4.6-p15, cu patch-urile de securitate din iulie și august 2026 aplicate, iar comanda security:patch-status nu raporta nicio problemă. Adobe Enterprise Support a confirmat pe 7 septembrie că lucrează la un fix. Buletinul APSB26-146 a apărut abia seara, la 20:20 UTC. Deci fixul a sosit la trei zile după primele atacuri, când orice magazin expus pe internet putea primi vizite nedorite.
CVE-2026-75650: de ce a luat scorul maxim
Pentru securitatea Magento, scorul acesta are o semnificație simplă. CVE-2026-75650 a primit 10.0 pe scara CVSS, maximul posibil pentru o vulnerabilitate. Vectorul tehnic spune restul: atac la distanță, complexitate redusă, fără privilegii și fără nicio interacțiune din partea utilizatorului. Adobe l-a trecut pe prioritatea 1, cea mai urgentă din scală. Categoria tehnică, CWE-1336, descrie o neutralizare incorectă a elementelor speciale într-un motor de template. Cu alte cuvinte, motorul acceptă conținut nepurificat, iar drumul spre executarea de cod e scurt.
Lista versiunilor afectate include practic tot ce e în suport astăzi. Adobe Commerce figurează pe ramurile 2.4.4 până la 2.4.9. B2B acoperă versiunile de la 1.3.3 la 1.5.3, iar Magento Open Source de la 2.4.6 la 2.4.9. Toate includeau și edițiile din august 2026. Nu e o eroare de admin, nu cere un cont valid și nu e o capcană de tip click. De aceea, un atacator care ajunge pe pagina publică a magazinului poate rula cod PHP ca utilizatorul serverului, fără nicio autentificare.
Cum a pătruns: mecanismul în două etape
Mecanismul începe cu o trăsătură aparent inofensivă din sistemul de template. Magento permite atașarea de proprietăți styles la elemente din layout, iar motorul le prelucrează ca date de încredere. Vulnerabilitatea transformă exact această încredere într-o poartă: atacatorul trimite o cerere GraphQL în care ascunde cod PHP printre proprietățile styles. Magento nu neutralizează conținutul și îl scrie pe disc ca parte dintr-o operație normală. Destinația poate fi, de exemplu, un raport de eroare generat de sistem. Sansec a numit tehnica smuggling tocmai pentru că payload-ul trece pe lângă filtrele obișnuite.
Etapa a doua e la fel de ingenioasă: execuția. Atacatorul provoacă deliberat o plată eșuată, iar Magento își trimite singur emailul standard Payment Transaction Failed Reminder. Nimeni nu trebuie să deschidă mesajul, pentru că codul rulează la compunerea șablonului, chiar dacă livrarea eșuează în cele din urmă. La redare, exploatarea redirecționează clasele de scanare din mecanismul de dependency injection spre fișierul otrăvit. PHP-ul din fișier se execută apoi ca utilizatorul web. Mutarea sesiunilor pe Redis sau pe bază de date nu oprește nimic.
Ce au lăsat atacatorii în magazine
Codul executat lasă în urmă un implant compact, scris în Rust. Procesul apare la început ca kworker, un nume care imită un proces intern al nucleului Linux. Pe 6 septembrie, versiuni noi s-au copiat în folderul ~/.cache/fontconfig sub numele fc-cache. A doua zi, implantul s-a redenumit chronyd, numele real al daemonului de timp. Comunicarea a urmat aceeași cale: pachete UDP pe portul 123, disimulate în trafic NTP, trec neobservate prin regulile de ieșire. Persistența vine din intrări cron care reporneesc implantul de două ori pe oră, iar unele versiuni se pot relansa singure, fără cron deloc.
Un al doilea atacator, independent, a intrat prin aceeași poartă. Pe 7 septembrie, Sansec a analizat un dropper PHP trimis prin antetul Store al cererii GraphQL. Codul scrie un web shell în cache-ul de imagini de produs, care răspunde 404 fără antetul corect. Sansec confirmă cel puțin doi operatori distincți pe aceleași victime. Mai mult, la publicarea analizei, implantul nu era recunoscut de niciun alt producător de securitate pe VirusTotal. Iar urmăritorul se verifică cu semnele concrete de mai jos:
- Emailuri neobișnuite de plăți eșuate. Valurile de notificări Payment Transaction Failed Reminder, generate fără plăți refuzate reale, sunt primul semnal.
- Procese cu nume împrumutate. Caută kworker, fc-cache sau chronyd în lista de procese; niciunul nu are ce căuta pornit de magazin.
- Fișiere ascunse în /tmp. Folderele .kw_, .cache_, .fc- sau .chrony-, cu binare în interior, trădează implantul.
- Cod PHP în directorul de media. Comanda find pub/media -name ‘*.php’ nu trebuie să returneze nimic.
- Intrări cron suspecte. Verifică direct fișierul spool, nu numai ieșirea comenzii crontab -l, pentru că unele variante scriu acolo fără urmă în syslog.
APSB26-146: fixul urgent explicat în detaliu
Răspunsul Adobe pentru securitatea Magento nu vine sub forma unei versiuni noi, ci a unui hotfix. Buletinul APSB26-146 trimite spre pachetul VULN-39341, un patch composer care se aplică pe linia de versiuni deja existentă. Coloana Updated Version din buletin conține literalmente textul Hotfix for CVE-2026-75650, iar scanarea după numărul de versiune nu confirmă nimic. Adobe a testat fixul pe edițiile 2026-aug ale tuturor ramurilor afectate, inclusiv B2B de la 1.3.3 la 1.5.3. Verificarea cu Quality Patches Tool: comanda vendor/bin/magento-patches -n status trebuie să afișeze starea Applied pentru VULN-39341. Pentru ramurile vechi scoase din suport există backport-uri Scandiweb, neverificate de Sansec, iar testarea pe staging rămâne obligatorie.
Fixul pentru securitatea Magento a intrat în magazinele noastre imediat ce Adobe a publicat buletinul. Echipa care administrează fiecare magazin online Magento 2 din portofoliu a aplicat hotfix-ul VULN-39341 în aceeași zi. Am confirmat starea Applied cu Quality Patches Tool, apoi am urmat cu rotația completă a credențialelor. Un detaliu rămâne neschimbat: versiunea afișată a magazinului e aceeași. Dovada fixului trăiește în lista de patch-uri, nu în numărul de versiune. Am detaliat această disciplină în articolul despre cât de repede se aplică un security update Magento 2.
Securitatea Magento după patch: rotația credențialelor
Patch-ul închide poarta, dar nu scoate pe nimeni din casă. Magazinele expuse între 4 și 7 septembrie au nevoie de un incident response real, nu numai de instalarea hotfix-ului. Securitatea Magento cere apoi rotația cheii de criptare și a tuturor credențialelor pe care le protejează. Cheia cifrează token-uri de integrare, credențiale de gateway de plată și token-uri de automatizare cu privilegii de sistem. De aceea, lista celor 15 pași poate fi comprimată fără pierderi mari:
- Cheia de criptare Magento, apoi tot ce protejează ea. O cheie schimbată nu invalidează nimic din ce atacatorul a citit deja, avertizează Adobe. Sansec recomandă și golirea sesiunilor, inclusiv Redis, înainte de rotație.
- Parolele de admin ale tuturor utilizatorilor. Fără excepții, inclusiv conturile folosite rar.
- Token-urile REST, SOAP și GraphQL ale integrărilor. Le regenerezi din System > Extensions > Integrations, împreună cu secretele OAuth ale aplicațiilor conectate.
- Credențialele gateway-urilor de plată, la furnizor. Stripe, Braintree, Adyen și PayPal se rotesc la ei, nu din Magento.
- Credențialele bazei de date și cheile SSH. Include și conturile de cron sau servicii cu privilegii ridicate.
- Cheile API ale extensiilor terțe. Transport, taxe și alte integrări conectate au propriile credențiale.
Greșelile de evitat se învârt în jurul acelorași capcane. Nu te opri la patch și nu considera crontabul gol o dovadă de curățenie, pentru că unele variante se relansează fără el. Nu reactiva GraphQL fără hotfix aplicat, dacă ai folosit dezactivarea ca măsură provizorie. Dacă valurile de emailuri de plăți eșuate au apărut în fereastra critică, pornește o verificare completă a serverului. Securitatea Magento în 2026 nu e un patch unic, e un ritm, iar ritmul acesta se poate delega. Dacă vrei fixurile de urgență în magazinul tău în ziua buletinului, scrie-ne o cerere de ofertă.
