Lo zero-day StyleSmuggler consente agli attaccanti di ottenere il controllo remoto di store Magento aggiornati

Una vulnerabilità finora sconosciuta, denominata StyleSmuggler, è attivamente sfruttata contro store Magento e Adobe Commerce, compresi i sistemi con gli aggiornamenti di sicurezza più recenti.

L’attacco consente l’esecuzione remota di codice senza autenticazione attraverso il motore di elaborazione dei template di Magento e la gestione correlata a GraphQL. Le intrusioni riuscite hanno installato una backdoor Linux basata su Rust e, in alcuni casi, una web shell PHP nascosta.

SecurityAffairs ha descritto pubblicamente la campagna il 7 settembre 2026, attribuendo a Sansec l’indagine tecnica. I primi tentativi di sfruttamento osservati risalgono al 4 settembre.

Non sono stati resi noti alcun identificativo CVE, punteggio CVSS o livello di gravità ufficiale assegnato da Adobe. Non è inoltre noto se la vulnerabilità sia presente nel catalogo delle vulnerabilità sfruttate note della Cybersecurity and Infrastructure Security Agency degli Stati Uniti.

Anche gli store aggiornati e completamente corretti restano esposti

StyleSmuggler interessa Magento Open Source e Adobe Commerce, ma non è ancora disponibile una matrice autorevole delle versioni coinvolte.

Sansec ha riprodotto l’exploit su installazioni pulite e ha identificato una prima vittima che eseguiva Magento 2.4.6-p15 con gli aggiornamenti di sicurezza di luglio e agosto 2026 installati. Le versioni attuali di Magento Open Source indicate nello specifico come vulnerabili includono:

• Magento Open Source 2.4.7
• Magento Open Source 2.4.8
• Magento Open Source 2.4.9

Un’altra fonte descrive tutte le versioni di Magento e Adobe Commerce come vulnerabili. Fino alla pubblicazione di un avviso da parte di Adobe, gli amministratori non devono presumere che una versione precedente, più recente o completamente aggiornata sia sicura.

L’esposizione è significativa. Secondo le stime, Magento è utilizzato da oltre 160.000 siti web, tra cui circa 14.000 dei primi un milione di siti. La compromissione del server può mettere a disposizione dell’attaccante i dati dei clienti, le credenziali amministrative, i token API, i segreti dei fornitori di servizi di pagamento, le password dei database e le chiavi di accesso al cloud.

Secondo quanto riferito, Adobe stava preparando una correzione. Era previsto un rilascio di sicurezza per l’8 settembre, ma non era noto se avrebbe incluso la correzione per StyleSmuggler.

Una notifica di pagamento non riuscito diventa il trigger per l’esecuzione

L’exploit prende di mira la pipeline di rendering dei template di Magento. Inietta codice PHP attraverso l’elaborazione associata alla proprietà styles e a GraphQL, aggirando i controlli progettati per rifiutare contenuti pericolosi nei template.

La catena osservata si articola in due fasi principali. Innanzitutto, un attaccante non autenticato crea o avvelena un record Magento contenente codice PHP malevolo. Un metodo dimostrato consiste nella generazione di un report sui pagamenti non riusciti.

Magento esegue successivamente il rendering della notifica standard Payment Transaction Failed Reminder. Durante questa operazione, la piattaforma valuta il contenuto avvelenato ed esegue il codice PHP incorporato sul server.

Nessun cliente o amministratore deve aprire un allegato o seguire un link. L’exploit può riuscire anche se l’e-mail di notifica non viene mai recapitata, perché l’esecuzione avviene durante il processo di rendering lato server di Magento.

Un aumento inspiegabile dei promemoria relativi ai pagamenti non riusciti può quindi indicare uno sfruttamento della vulnerabilità. Non costituisce però una prova definitiva, poiché anche i normali errori di pagamento generano lo stesso tipo di notifica.

La modifica del backend delle sessioni di Magento non blocca l’attacco in modo affidabile. In un incidente, un tentativo che coinvolgeva l’archiviazione delle sessioni non è andato a buon fine. Otto secondi dopo, lo stesso operatore è passato a un file caricato attraverso la funzionalità delle opzioni personalizzate di Magento, riuscendo a eseguire il codice.

Questo rapido cambio di strategia indica che gli attaccanti stanno adattando attivamente i propri metodi di distribuzione. Le difese basate su una singola posizione del payload o su un unico schema di proof of concept difficilmente saranno sufficienti.

La backdoor Rust si nasconde dietro nomi di processi Linux e traffico NTP

Gli attacchi riusciti hanno distribuito un impianto Linux compatto basato su Rust. Il malware opera in background, si connette a un’infrastruttura controllata dall’attaccante e resta in attesa di comandi.

Al momento della pubblicazione dei risultati non erano stati osservati comandi successivi provenienti dall’impianto. Tuttavia, un host che esegue la backdoor deve comunque essere considerato compromesso, poiché l’operatore conserva la capacità di impartire comandi da remoto.

Il malware ha modificato il proprio camuffamento del processo tra i diversi campioni:

• Un primo campione appariva come [kworker/u:8:0]
• Una variante osservata il 6 settembre utilizzava fc-cache
• Un campione osservato il 7 settembre utilizzava chronyd

Questi nomi imitano rispettivamente un worker del kernel, l’utility Linux per la cache dei caratteri e un comune demone per la sincronizzazione dell’ora. I soli nomi dei processi non consentono di distinguere l’impianto dal software legittimo.

La versione fc-cache si copiava in ~/.cache/fontconfig/fc-cache, creava un file di blocco PID e impostava la persistenza tramite cron. Il task pianificato rilanciava l’impianto ogni 30 minuti.

Altre build utilizzavano metodi di persistenza diversi. Una variante di chronyd si affidava a cron, mentre un’altra si riavviava senza lasciare una voce cron visibile. Un crontab vuoto non dimostra quindi che il server sia pulito.

I primi campioni comunicavano tramite TLS e WebSockets. Le versioni più recenti camuffano il traffico di comando e controllo da attività del Network Time Protocol inviando pacchetti UDP alla porta 123.

L’impianto risolve ntp.timesync.to ogni 60 secondi e trasmette pacchetti da 48 byte simili alle risposte di un server NTP. Solo i primi quattro byte seguono una struttura convenzionale simile a quella NTP. I dati restanti possono contenere l’identificativo dell’impianto, il nome host, il nome utente, la versione del sistema operativo, il tempo di attività, l’utilizzo di memoria e disco, lo stato di root e la versione del malware.

Il 7 settembre, i domini osservati risultavano associati a 185.157.160.251. La backdoor può inoltre interrogare ipify, icanhazip, ident.me e ipinfo.io per determinare l’indirizzo IP pubblico del server.

Prima di inviare i beacon, controlla il valore TracerPid di Linux per individuare eventuali attività di debugging o tracing. Se rileva un’attività di tracing, il malware si installa comunque ma sopprime le comunicazioni di rete.

Un secondo attore ha nascosto una web shell nelle directory della cache delle immagini

Gli investigatori hanno trovato anche prove dell’attività di un operatore apparentemente distinto, che sfruttava gli store compromessi. Questo attore ha installato un piccolo dropper PHP che scriveva una web shell nella cache delle immagini dei prodotti di Magento.

La shell era collocata sotto nomi di directory simili a hash, così da confondersi con i contenuti generati dalla cache. Normalmente restituiva una risposta 404 dall’aspetto ordinario.

La funzionalità malevola diventava disponibile solo quando una richiesta includeva l’header X-Cache-Token corretto. La shell eseguiva quindi il codice PHP ricevuto tramite un parametro POST.

Prima di installare la shell, il dropper contattava:

457cfa2fb7p5.daf892t5qau4og8pi4cghbc6fhm1dim3u.oast.site

L’indirizzo appartiene a un servizio pubblico di test out-of-band, comunemente utilizzato per confermare l’esecuzione di codice iniettato. Il payload recuperato proveniva da un header di richiesta Magento Store, mentre i tag PHP erano ancora con escape JSON nel record memorizzato da Magento.

Di conseguenza, rimuovere un processo Rust visibile non è sufficiente. Un server interessato può contenere anche record modificati, template avvelenati, payload caricati, persistenza tramite cron e shell PHP nascoste in percorsi scrivibili dei media o della cache.

Gli indicatori che i difensori devono verificare subito

Gli operatori Magento dovrebbero correlare i dati di telemetria applicativi, dell’host, DNS e di rete, invece di affidarsi a un singolo indicatore. I controlli prioritari includono:

• Picchi nell’attività Payment Transaction Failed Reminder
• Tag PHP o tag PHP con escape JSON imprevisti nei record Magento
• Template modificati, report sospetti e caricamenti insoliti tramite le opzioni personalizzate
• Processi denominati [kworker/u:8:0], fc-cache o chronyd eseguiti da percorsi anomali
• Il file ~/.cache/fontconfig/fc-cache
• Job cron che eseguono binari sospetti ogni 30 minuti
• Messaggi ripetuti crontab: command not allowed relativi ad account come www-data
• File PHP sotto pub/media, in particolare nelle directory della cache delle immagini dei prodotti
• Richieste contenenti l’header X-Cache-Token
• Richieste DNS per ntp.timesync.to
• Connessioni che coinvolgono 185.157.160.251
• Traffico UDP/123 in uscita imprevisto o pacchetti simili a NTP da 48 byte
• Il dominio OAST indicato nei log di Magento, del server web, DNS o proxy

Un processo chronyd dall’aspetto legittimo che genera ogni minuto nove pacchetti rapidi in modalità server NTP è particolarmente sospetto. Gli amministratori dovrebbero confrontare questo traffico con le sorgenti temporali configurate sull’host e con il normale comportamento di sincronizzazione.

Gli indicatori possono cambiare rapidamente. La campagna ha già modificato nomi dei processi, tecniche di persistenza e percorsi di sfruttamento tra il 6 settembre e il 7 settembre.

Disabilitare GraphQL quando possibile e considerare le rilevazioni come una compromissione

Fino al rilascio e all’applicazione di una correzione ufficiale da parte di Adobe, Sansec raccomanda di disabilitare temporaneamente GraphQL ove possibile dal punto di vista operativo. Questa misura può interrompere le funzionalità dello store o le integrazioni esterne; le organizzazioni dovrebbero quindi testarne gli effetti e valutare controlli compensativi nei casi in cui GraphQL non possa essere disabilitato.

I team dovrebbero esaminare le directory Magento scrivibili, i file di spool di cron, gli alberi dei processi, i log di autenticazione, i log del server web, la cronologia DNS e il traffico UDP/123 in uscita. La presenza di un qualsiasi indicatore di StyleSmuggler dovrebbe far scattare l’isolamento dell’host e la conservazione dei dati forensi.

La risposta all’incidente dovrebbe includere anche la rotazione delle password degli amministratori Magento, dei token API, delle credenziali del database, dei segreti dei fornitori di servizi di pagamento e delle chiavi cloud accessibili dal server. Prima di ripristinare il servizio, gli incaricati della risposta dovrebbero cercare web shell secondarie, record malevoli, template alterati, eseguibili caricati e forme di persistenza esterne a cron.

Uno stato di aggiornamento pulito non protegge da questa campagna. Fino alla disponibilità di una correzione verificata, i sistemi Magento e Adobe Commerce esposti dovrebbero essere monitorati come potenzialmente vulnerabili; i sistemi che mostrano indicatori correlati devono invece essere gestiti come già compromessi.