Per favore, aggiungi TurboLab.it alle eccezioni del tuo Ad Blocker. Siamo un progetto no-profit, e la pubblicità è indispensabile per pagare le spese.
In alternativa, puoi sostenerci con una donazione.
Rispetteremo ogni tua scelta, e potrai sempre utilizzare il sito senza limitazioni.
Un negozio Magento aggiornato all'ultimo livello di patch che Adobe mette a disposizione per la sua linea, con security:patch-status pulito, compromesso lo stesso. È la prima vittima confermata di StyleSmuggler, la vulnerabilità zero-day che permette l'esecuzione di codice da remoto senza autenticazione su Magento Open Source e Adobe Commerce, e che gli aggressori stanno sfruttando in questo momento contro i negozi online.
La vulnerabilità è stata catalogata con l'identificativo CVE-2026-75650, gravità 10. Adobe ha trattato il problema nel bollettino APSB26-146 e reso disponibile una patch di emergenza, da applicare il prima possibile. È scaricabile da qui per tutte le versioni supportate.
La falla è stata individuata e battezzata dalla società di sicurezza olandese Sansec, che ha pubblicato l'advisory il 5 settembre 2026, con gli attacchi già in corso dalla sera del 4 settembre. «Sansec pubblica in anticipo perché in questo momento i negozi vengono compromessi», ha spiegato l'azienda, giustificando la divulgazione prima di qualsiasi correzione. Perché una correzione, ad oggi, non esiste: Adobe non ha pubblicato un advisory, non ha assegnato un identificativo CVE, non ha rilasciato una patch e non ha nemmeno indicato una soluzione alternativa ufficiale.
L'attacco si articola in due momenti distinti. Nel primo, l'aggressore invia una richiesta POST verso l'endpoint /graphql manipolando le proprietà styles: il codice PHP malevolo finisce così dentro un file che Magento genera durante il normale funzionamento, ad esempio un report di pagamento fallito. Secondo Sansec, StyleSmuggler «inietta codice malevolo nel sistema di template di Magento» sfruttando proprio quelle proprietà per «eludere le protezioni esistenti».
La seconda fase è quella che rende la vicenda particolarmente sgradevole: l'exploit induce la piattaforma a generare l'email di promemoria per transazione di pagamento fallita, e il codice avvelenato viene eseguito lato server durante il rendering del messaggio, «mentre Magento lo renderizza». Prima che l'email venga spedita, ricevuta o aperta. Nessun click, nessun phishing, nessuna interazione dell'utente: è una funzione legittima della piattaforma che fa esattamente ciò per cui è stata costruita. Ne consegue un dettaglio importante per chi cerca conferme: un sistema di posta in uscita silenzioso o non funzionante non è affatto una prova di sicurezza, perché l'esecuzione avviene comunque a monte.
Sansec ha riprodotto l'intera catena non autenticata su installazioni pulite di Magento Open Source 2.4.7, 2.4.8 e 2.4.9. La prima vittima confermata girava invece su 2.4.6-p15 con le patch di sicurezza di luglio e agosto 2026 applicate. Sul fronte Adobe Commerce, invece, Sansec non ha pubblicato una riproduzione specifica e Adobe non ha confermato quali versioni dei propri prodotti siano coinvolte.
Gli attacchi riusciti installano una backdoor persistente scritta in Rust, un binario da 1,9 MB compilato per x86-64 e ARM64. Si maschera da thread del kernel Linux con il nome [kworker/u:8:0] oppure, in una variante più recente, da fc-cache, copiandosi in ~/.cache/fontconfig/fc-cache. La persistenza passa da cron, con scrittura diretta nel file di spool per aggirare il logging standard: Sansec documenta per la variante fc-cache una riga 13,43 * * * *, quindi due riavvii l'ora, mentre altre ricostruzioni della vicenda parlano di un riavvio ogni cinque minuti - plausibilmente build diverse dello stesso impianto.
Il traffico verso il server di comando e controllo, all'indirizzo IP 99.84.67.186, è camuffato da sincronizzazione oraria: ogni 60 secondi il processo risolve ntp.timesync.to e invia pacchetti UDP da 48 byte sulla porta 123, dove solo i primi quattro byte sono NTP autentico e il resto trasporta un record MessagePack con identificativo dell'agente, hostname, utente, versione del sistema operativo, uso di memoria e disco, uptime e privilegi di root. Un travestimento pensato per attraversare indenne il filtraggio in uscita. Alcune varianti rinunciano del tutto alle connessioni esterne e interrogano l'istanza Redis locale per rubare i dati di sessione, tagliando fuori qualsiasi monitoraggio di rete. Il malware modifica inoltre il proprio binario in memoria: per rilevarlo occorre calcolare l'hash sia del file su disco sia del processo in esecuzione.
Che lo sfruttamento sia reale lo conferma anche Disrex Group, società di hosting e sviluppo Magento, che il 5 settembre 2026 ha pubblicato un repository di risposta agli incidenti. Disrex ha gestito due negozi compromessi e un terzo attaccato senza successo, tutti su Magento Open Source e ospitati sulla propria infrastruttura. Il caso più istruttivo è quello che l'azienda chiama "Store A": Magento Open Source 2.4.8, cliente Sansec Shield con il modulo installato, attivo e regolarmente licenziato, colpito alle 23:10 UTC del 4 settembre, ore prima che entrassero in funzione le prime regole di blocco specifiche per questa falla. Shield stava bloccando altro traffico malevolo, ma non questo. Il secondo negozio girava su 2.4.7-p2, un livello di patch che risale ad agosto 2024.
La mitigazione immediata, raccomandata da tutti, è disattivare temporaneamente GraphQL fino al rilascio di una correzione ufficiale. Come ricorda Disrex, gli storefront headless e le progressive web app hanno bisogno di GraphQL per funzionare, mentre la maggior parte dei frontend classici e di quelli basati su Hyvä può farne a meno senza conseguenze. A livello di server aiuta disabilitare proc_open e montare le directory temporanee con il flag noexec, in modo da bloccare l'esecuzione del payload. Circolano anche patch non ufficiali della community, firmate Disrex, ProxiBlue e Graycore, che irrobustiscono specifiche classi di Magento senza però risolvere la vulnerabilità.
Per la verifica, Sansec suggerisce di cercare voci sospette nel crontab, controllare la presenza di processi kworker o fc-cache, ispezionare percorsi come ~/.local/share/.gvfsd/, /tmp/.kw_* e /tmp/.cache_*, e cercare la stringa x_trace_ dentro var/report/. Attenzione però: alcuni negozi compromessi presentavano tracce anche in var/log/system.log. E la backdoor non risultava riconosciuta, al momento, da nessun vendor di sicurezza al di fuori di Sansec.
Il prossimo rilascio di sicurezza programmato da Adobe è previsto per domani, 8 settembre 2026, ma nessuno ha confermato che comprenda una correzione per StyleSmuggler. Nel frattempo non risulta pubblicato alcun proof of concept: gli unici a saper sfruttare la falla, per ora, sono quelli che la stanno già usando.
Nessuno ha ancora commentato.
