StyleSmuggler buca Magento: zero-day RCE installa backdoor nei negozi online

🛡️ Executive Summary

• StyleSmuggler sfrutta una zero-day senza autenticazione per ottenere esecuzione di codice sui server Magento; gli attacchi sono iniziati il 4 settembre.
• Sansec riproduce la catena su Magento Open Source 2.4.7, 2.4.8 e 2.4.9 e osserva vittime già aggiornate con le patch Adobe.
• Al 6 settembre non esistono patch Adobe ufficiali: occorre cercare processi kworker fasulli, cron persistenti, log avvelenati e disabilitare temporaneamente GraphQL.

Una nuova zero-day di Magento Open Source e Adobe Commerce, battezzata StyleSmuggler, viene sfruttata attivamente per ottenere remote code execution senza autenticazione e installare una backdoor persistente sui server dei negozi online. La società olandese Sansec ha rilevato i primi attacchi il 4 settembre 2026 e ha riprodotto la catena completa su installazioni pulite di Magento 2.4.7, 2.4.8 e 2.4.9. Ancora più significativo è il primo caso investigato: la vittima utilizzava 2.4.6-p15 con gli aggiornamenti Adobe di luglio e agosto già applicati. Al 6 settembre Adobe non ha ancora pubblicato CVE, advisory, patch o workaround ufficiali specifici per StyleSmuggler, trasformando la vulnerabilità in un problema operativo immediato per gli e-commerce esposti a Internet.

StyleSmuggler ottiene RCE senza login attraverso il sistema dei template Magento

L’analisi tecnica pubblicata da Sansec descrive un attacco in due fasi che utilizza funzionalità legittime della piattaforma per trasformare dati controllati dall’aggressore in codice PHP eseguibile. Il primo passaggio consiste nell’avvelenare un file scritto direttamente da Magento, per esempio generando intenzionalmente un failure report oppure manipolando i log dell’applicazione. Successivamente l’attaccante induce Magento a processare quel contenuto attraverso il normale sistema dei template, sfruttando proprietà styles costruite in modo da aggirare le protezioni esistenti. Uno dei trigger individuati passa attraverso la funzione Payment Transaction Failed Reminder: il codice malevolo viene eseguito mentre Magento genera l’email relativa a un pagamento fallito, senza che il destinatario debba aprire il messaggio e persino se l’invio della mail non riesce. La superficie è particolarmente delicata perché un negozio aggiornato può quindi essere compromesso partendo da una richiesta remota non autenticata, senza necessità di credenziali amministrative. L’episodio segue una lunga serie di problemi nell’ecosistema Adobe Commerce, compresi upload arbitrari ed esecuzione di codice corretti nel ciclo di sicurezza di luglio, ma in questo caso manca ancora una correzione ufficiale.

Anche Magento 2.4.9 risulta vulnerabile e le patch di agosto non bastano

Sansec dichiara di aver riprodotto l’intera catena non autenticata su Magento Open Source 2.4.7, 2.4.8 e 2.4.9, mentre il primo sistema compromesso esaminato utilizzava la release 2.4.6-p15 con gli aggiornamenti di sicurezza Adobe di luglio e agosto. Questo dettaglio impedisce di considerare sufficiente la semplice verifica dello stato delle patch: il comando security:patch-status risultava pulito anche sulla vittima. La portata esatta per Adobe Commerce e Adobe Commerce Cloud non è stata ancora confermata direttamente dal produttore e Sansec non ha pubblicato una riproduzione completa su tutte queste configurazioni, quindi il perimetro deve essere distinto dalle versioni Magento testate concretamente. L’indice ufficiale dei bollettini Adobe Commerce, aggiornato al momento della verifica con APSB26-92 dell’11 agosto come ultimo advisory disponibile, non contiene ancora StyleSmuggler. Adobe aveva già corretto in quel ciclo vulnerabilità capaci di produrre privilege escalation, security feature bypass ed esecuzione di codice, ma la nuova campagna dimostra che anche installazioni pienamente allineate all’ultimo patch level possono restare esposte a una vulnerabilità sconosciuta al normale processo di aggiornamento.

Leggi anche: Google Tag Manager usato per rubare carte di credito dai siti Magento

La backdoor si maschera da processo kernel e si reinstalla ogni cinque minuti

Dopo l’esecuzione iniziale, StyleSmuggler scarica un impianto persistente che cerca di confondersi con i processi del sistema Linux. Sansec ha osservato un processo chiamato [kworker/u:8:0], denominazione costruita per imitare i kernel worker legittimi, mentre il binario viene salvato sotto la home dell’utente che esegue il sito in ~/.local/share/.gvfsd/gvfsd-user oppure attraverso varianti collocate in /tmp. La persistenza viene ottenuta scrivendo una voce cron che riavvia l’impianto ogni cinque minuti. Le indagini indipendenti di Disrex su due negozi compromessi hanno mostrato quanto questa persistenza possa essere aggressiva: su un sistema la stessa riga cron era stata scritta 1.728 volte e veniva ripristinata quasi immediatamente dopo la rimozione. Il malware è stato descritto come un binario Rust staticamente linkato, disponibile per architetture x86-64 e arm64. In almeno uno degli ambienti osservati il processo non stabiliva connessioni evidenti verso Internet ma manteneva numerose sessioni con il server Redis locale sulla porta 6379, dal quale poteva leggere lo storage delle sessioni Magento. La compromissione di un server e-commerce non implica quindi necessariamente uno skimmer immediatamente visibile nel checkout: la backdoor può mantenere accesso, leggere sessioni e preparare ulteriori attività prima di mostrare traffico esterno.

WebSocket, traffico simile a NTP e cron costruiscono il secondo livello dell’attacco

Gli indicatori pubblicati da Sansec mostrano un’infrastruttura articolata. Il dominio 247.cdnflare[.]xyz viene utilizzato come punto di download del malware, mentre 99.84.67[.]186:443 è associato a traffico C2 WebSocket su TLS. La ricerca indica inoltre windwsecurity[.]run per una remote shell e diversi domini che utilizzano la porta UDP 123 con un protocollo personalizzato costruito per assomigliare al normale traffico NTP. Il tentativo di confondersi con servizi ordinari segue una tendenza ormai ricorrente nelle operazioni contro applicazioni web, dove processi, protocolli e servizi legittimi vengono imitati per ridurre l’efficacia della detection basata esclusivamente sugli indicatori statici. I responsabili degli e-commerce devono quindi verificare non soltanto i file presenti nel document root, ma anche home directory dell’utente web, /tmp, crontab, processi in memoria e session storage Redis. Questo aspetto è importante perché una scansione limitata alla directory del sito può restituire un risultato pulito anche quando il malware è già attivo fuori dal web root.

I log Magento vengono avvelenati e l’email di pagamento fallito può essere il primo segnale

L’indagine ha individuato almeno due posizioni utilizzabili nella prima fase della catena. Sansec suggerisce di cercare il marker X_TRACE_ all’interno di var/report/, ma Disrex ha osservato compromissioni in cui il codice veniva introdotto invece in var/log/system.log. Gli aggressori hanno inoltre già modificato la forma dell’header utilizzato durante le prime ore della campagna, rendendo fragile una detection basata sull’esatta stringa iniziale. Un altro indicatore pratico è rappresentato da improvvisi messaggi Payment Transaction Failed Reminder apparentemente anomali. In uno dei casi investigati, il proprietario del negozio ha ricevuto una mail con variabili Magento non risolte, indirizzo cliente su dominio .invalid e importo pari a zero: il messaggio ha fatto scattare l’analisi che ha portato alla scoperta della backdoor. Non tutti i messaggi di pagamento fallito indicano naturalmente un attacco, ma un aumento improvviso o contenuti chiaramente corrotti devono essere trattati come un segnale da verificare. Il rischio per gli e-commerce è particolarmente elevato perché le compromissioni delle piattaforme di vendita possono evolvere verso furto di sessioni, credenziali e dati finanziari, come già avvenuto nelle campagne Magecart basate su web-skimming persistente.

Senza patch Adobe la mitigazione deve ridurre immediatamente la superficie esposta

Al 6 settembre 2026 non esiste ancora una patch ufficiale Adobe specifica per StyleSmuggler. Sansec raccomanda agli amministratori che non utilizzano le proprie protezioni di disabilitare temporaneamente GraphQL in attesa della correzione del vendor. La misura ha però conseguenze operative: storefront headless e Progressive Web App dipendono spesso da GraphQL, mentre molte implementazioni classiche possono funzionare senza esporlo. Sono inoltre comparsi workaround indipendenti che cercano di impedire l’esecuzione via HTTP di alcune classi Magento destinate al compilatore Dependency Injection, ma non sono fix ufficiali e non devono essere considerati equivalenti a una patch Adobe. Disrex consiglia ulteriori livelli di contenimento lato server, compresa la disabilitazione di proc_open tra le funzioni PHP disponibili e il montaggio di /tmp, /var/tmp e /dev/shm con noexec, così da ostacolare l’esecuzione dei binari scaricati. Le regole WAF o nginx che bloccano i parametri osservati nelle query HTTP possono fermare la campagna attuale, ma non necessariamente la vulnerabilità: gli stessi parametri possono essere trasferiti nel corpo di una richiesta POST o JSON.

Continua con:

• FunnelKit trasforma i checkout WooCommerce in skimmer di carte di credito
• Adobe Commerce corregge una escalation senza autenticazione nel Patch Day di agosto

Un negozio aggiornato deve essere trattato come potenzialmente compromesso se esposto durante gli attacchi

StyleSmuggler cambia soprattutto il criterio con cui gli amministratori devono valutare il rischio: essere aggiornati non equivale, in questo momento, a essere protetti. Gli attacchi sono iniziati il 4 settembre, Sansec ha pubblicato l’allerta il giorno successivo e Adobe non ha ancora rilasciato una soluzione ufficiale. I negozi esposti durante questa finestra devono quindi cercare attivamente gli indicatori di compromissione anziché limitarsi ad attendere il prossimo aggiornamento. Se viene individuato il processo [kworker/u:8:0] eseguito da un utente non root, un binario gvfsd-user, cron sospetti o tracce coerenti nei log, la risposta deve essere quella prevista per un incidente già avvenuto: preservare prima le evidenze, eliminare il meccanismo di persistenza prima di terminare il processo, invalidare le sessioni Magento e ruotare password amministrative, chiavi di integrazione, credenziali dei provider di pagamento e segreti presenti in app/etc/env.php. Sansec segnala il 8 settembre come prossimo ciclo programmato di sicurezza Adobe, ma non è ancora confermato che includa la correzione di StyleSmuggler. Fino ad allora, monitoraggio e contenimento diventano parte integrante della mitigazione di una zero-day già trasformata in campagna reale.