StyleSmuggler: zero-day Magento in attacco dal 4 settembre, nessuna patch

Una vulnerabilità zero-day denominata StyleSmuggler sta colpendo Magento Open Source e Adobe Commerce dal 4 settembre 2026, ore 22:40 UTC. La società di sicurezza Sansec, che ha scoperto e documentato la minaccia, ha confermato la riproduzione della catena di exploit su installazioni pulite delle versioni 2.4.7, 2.4.8 e 2.4.9. Adobe non ha pubblicato advisory, identificatore CVE, patch o workaround al 6 settembre 2026, lasciando i merchant di e-commerce a gestire un rischio di compromissione completa del server con strumenti non ufficiali.

Come funziona la catena di attacco

Il meccanismo di StyleSmuggler si articola in due stadi. Il primo è un'iniezione di codice PHP in un file che Magento stesso scrive durante le operazioni normali. Il secondo è l'esecuzione forzata di quel codice tramite il rendering del template email standard denominato 'Payment Transaction Failed Reminder'. La condizione critica è che l'esecuzione avviene indipendentemente dal fatto che l'email venga effettivamente consegnata: il semplice processo di rendering del template è sufficiente a innescare il payload.

Sansec ha documentato che la manipolazione avviene attraverso proprietà `styles` nel sistema di templating, e che la catena è riproducibile senza alcuna forma di autenticazione. Questo significa che un attaccante remoto può ottenere esecuzione di codice arbitrario sul server senza credenziali valide, superando ogni controllo di accesso basato su autenticazione.

L'implant Rust e la persistenza silenziosa

Una volta ottenuta l'esecuzione, il payload installa un backdoor con caratteristiche progettate per la persistenza e la mimetizzazione. Il binario è un programma Rust, stripped e staticamente linkato, di dimensione pari a circa 1,9 MB, compilato per entrambe le architetture x86-64 e arm64. Il processo in background si presenta con il nome `[kworker/u:8:0]`, una mascheratura che imita i kernel worker thread legittimi di Linux e che può ingannare ispezioni superficiali dei processi di sistema.

Il file viene collocato nel percorso `~/.local/share/.gvfsd/gvfsd-user` e la persistenza è garantita da un job cron che lo riavvia ogni 5 minuti. Il Disrex Group, che ha gestito indipendentemente due store compromessi e uno attaccato ma non violato, ha riportato un caso con 1.728 linee cron duplicate presenti sul sistema. L'implant ha inoltre mostrato di mantenere 28 connessioni contemporanee verso la session storage Redis sulla porta 6379, permettendo l'estrazione di dati senza stabilire connessioni C2 esterne rilevabili attraverso il perimetro di rete.

Sansec ha dichiarato di non avere "indication that the backdoor was actually used" sui sistemi osservati, il che lascia aperta la questione dello scopo finale dell'operazione: furto di dati di pagamento, accesso persistente per attacchi futuri, o entrambi.

La disclosure forzata e il vuoto di Adobe

La decisione di Sansec di pubblicare prima della disponibilità di patch ufficiali è motivata dalla constatazione che "stores are being compromised right now", come recita la citazione diretta dell'advisory. La timeline documentata mostra una sequenza serrata: prima exploitation confermata alle 22:40 UTC del 4 settembre, primi flag del sistema eComscan su store non correlati alle 23:10 UTC, inizio del blocco attacchi da parte di Sansec Shield alle 07:15 UTC del 5 settembre.

Al 6 settembre 2026, Adobe non ha pubblicato advisory, CVE, patch o workaround. La prossima release di sicurezza è programmata per l'8 settembre 2026, ma né Sansec né The Hacker News hanno confermato che questa includerà la correzione per StyleSmuggler. La prima vittima nota eseguiva Magento 2.4.6-p15 con le patch di luglio e agosto 2026 applicate e con lo stato di patch segnalato come "clean", indicando che le contromisure di sicurezza recenti non sono sufficienti a bloccare la minaccia.

"Sansec is publishing early because stores are being compromised right now" — Sansec, advisory StyleSmuggler

Cosa fare adesso

Sansec ha indicato una mitigazione temporanea specifica: la disabilitazione di GraphQL in attesa del rilascio della patch Adobe. Questa azione ha impatto sulle funzionalità frontend e API che dipendono da GraphQL, ma interrompe la superficie di attacco verificata. Disrex Group ha pubblicato regole nginx e Apache di mitigazione basate su traffico catturato, raccolto in due catture di pacchetti di oltre 200 MB ciascuna, e ha reso disponibile un repository di incident-response con indicatori e controlli.

I merchant dovrebbero inoltre verificare la presenza del processo `[kworker/u:8:0]` eseguito da utente non-root, del file `~/.local/share/.gvfsd/gvfsd-user`, e di job cron con intervallo di 5 minuti che puntino a percorsi sospetti nella home directory utente. Sansec ha rilasciato gli hash SHA-256 del binario per facilitare la ricerca sui sistemi. L'eComscan nella versione 1.9.7 termina il processo per i clienti Shield, ma Disrex ha documentato almeno un caso di mancato rilevamento nonostante la presenza massiccia di linee cron sospette.

Il rischio delle mitigazioni di emergenza

Il repository di Disrex contiene un disclaimer esplicito nel README: "This repository was written with AI assistance, during a live incident, in a few hours". Questa annotazione svela la pressione temporale sotto cui gli operatori di sicurezza hanno dovuto costruire strumenti di difesa in assenza di coordinamento vendor. La situazione mette in luce una fragilità strutturale del modello di disclosure coordinata: quando un vendor lascia i propri clienti esposti per giorni senza nemmeno un advisory preliminare, la responsabilità della protezione viene trasferita a ricercatori indipendenti e hosting provider, con il rischio di mitigazioni incomplete o non testate in produzione.

Non emerge sovrapposizione infrastrutturale tra gli indicatori C2 pubblicati da Sansec e altri gruppi noti allo stato attuale, né è possibile confermare la completezza della catena di exploit ricostruita da Disrex rispetto a quella originale. Sansec non ha riprodotto la vulnerabilità su Adobe Commerce on Cloud, lasciando aperta la questione della portata esatta sulla piattaforma cloud gestita.

Perché la situazione è critica

Migliaia di negozi di e-commerce operano su Magento con un modello di minaccia che non richiede autenticazione né interazione utente. La combinazione di RCE non autenticato, backdoor persistente con mimetizzazione a livello kernel, e accesso diretto alla session storage Redis configura uno scenario di compromissione totale del server. Il fatto che la prima vittima avesse patch di sicurezza recenti suggerisce che la vulnerabilità risiede in un componente non coperto dai cicli di patch regolari, o in una logica di template system sottovalutata dal processo di hardening standard.

La prossima settimana sarà determinante: se la release Adobe dell'8 settembre non includerà la correzione, i merchant dovranno gestire un fine settimana di esposizione prolungata con strumenti di terze parti, nel migliore dei casi, o con la disabilitazione funzionale di componenti critiche del proprio storefront.

Le informazioni sono state verificate sulle fonti citate e aggiornate al momento della pubblicazione.

Fonti

• https://thehackernews.com/2026/09/unpatched-magento-and-adobe-commerce.html
• https://www.helpnetsecurity.com/2026/09/04/google-chrome-zero-day-cve-2026-85046/
• https://www.helpnetsecurity.com/2026/09/04/scam-texts-peak-research/
• https://sansec.io/research/stylesmuggler
• https://nvd.nist.gov/vuln/detail/cve-2026-85046
• https://www.helpnetsecurity.com/2026/02/16/google-patches-chrome-vulnerability-with-in-the-wild-exploit-cve-2026-2441/
• https://www.helpnetsecurity.com/2026/04/01/google-chrome-zero-day-cve-2026-5281/
• https://www.helpnetsecurity.com/2026/06/09/google-chrome-zero-day-cve-2026-11645/