StyleSmuggler colpisce Magento: RCE senza patch e store già…

StyleSmuggler è una vulnerabilità zero-day RCE non autenticata in Magento e Adobe Commerce, attivamente sfruttata dal 4 settembre 2026. Adobe non ha ancora

Sansec ha scoperto e denominato StyleSmuggler il 5 settembre 2026, pubblicando advisory in anticipo rispetto alla routine perché gli attacchi erano già in corso. La vulnerabilità consente Remote Code Execution non autenticata su tutte le versioni correnti di Magento Open Source e Adobe Commerce, incluse le installazioni completamente aggiornate. Adobe non ha rilasciato patch, CVE o workaround al 6 settembre 2026, lasciando i merchant senza difesa ufficiale.

Punti chiave

StyleSmuggler è unauthenticated RCE che interessa Magento Open Source e Adobe Commerce 2.4.7, 2.4.8, 2.4.9, anche con patch di sicurezza complete
Gli attacchi attivi sono iniziati il 4 settembre 2026; la prima vittima documentata eseguiva Magento 2.4.6-p15 con gli aggiornamenti Adobe di luglio e agosto 2026 applicati
L'attacco sfrutta richieste GraphQL per iniettare PHP nei file di log, con esecuzione triggerata dal rendering server-side dell'email "Payment Transaction Failed Reminder"
L'implant post-exploitation è un binario Rust di circa 1.9 MB che si maschera da kernel thread, persiste via cron e può estrarre dati da Redis locale senza connessioni outbound

Come funziona l'attacco a due stadi

Il meccanismo tecnico si articola in due fasi sequenziali. Nella prima, l'attaccante invia richieste GraphQL manipolate che sfruttano la proprietà styles per iniettare codice PHP all'interno dei file di log o di report del sistema. Sansec ha documentato l'iniezione tramite var/report/; Disrex Group ha verificato indipendentemente che entrambi i store da essa gestiti erano stati compromessi attraverso var/log/system.log, un percorso alternativo che avrebbe aggirato controlli mirati alla sola directory report.

Nella seconda fase, il codice iniettato viene eseguito quando il server genera l'email amministrativa "Payment Transaction Failed Reminder". Il rendering server-side del template attiva il payload senza necessità di interazione umana, né apertura di email da parte di vittime. Questa architettura rende l'attacco completamente automatizzabile e scalabile.

Il marker di riconoscimento dell'attacco ha già mutato nel corso delle prime ore. Disrex ha osservato header nella forma X-TRACE- seguito da dieci caratteri esadecimali nella mattina del 5 settembre, e la stessa struttura priva della parola "TRACE" già nel pomeriggio dello stesso giorno. La velocità di adattamento suggerisce attività di test e affinamento in tempo reale.

L'implant Rust e la strategia di evasione

Post-compromissione, l'attaccante distribuisce un binario Rust staticamente linkato di circa 1.9 MB, compilato per architetture x86-64 e arm64. Il processo viene mascherato con il nome [kworker/u:8:0], riproducendo la convenzione di naming dei thread kernel Linux per eludere il rilevamento visivo nelle liste di processi.

La persistenza è ottenuta tramite entry cron scritta direttamente in /var/spool/cron/crontabs/. In uno dei store analizzati da Disrex, la stessa linea cron risultava replicata 1.728 volte. Il binario viene collocato in ~/.local/share/.gvfsd/gvfsd-user, un percorso che mima il demonte di virtual filesystem GNOME.

Una caratteristica distintiva documentata da Disrex riguarda il comportamento di rete dell'implant. Su almeno un store, il binario non ha stabilito connessioni outbound né verso host di download né verso infrastrutture di comando e controllo. Ha invece mantenuto 28 connessioni simultanee all'istanza Redis locale sulla porta 6379, leggendo direttamente le sessioni Magento. Questo pattern operativo riduce la superficie di rilevamento network-based e sfrutta la trust boundary interna dell'architettura applicativa.

La "patch irrelevance" e il silenzio di Adobe

Il caso documentato più dettagliatamente riguarda un merchant che eseguiva Magento 2.4.6-p15 con le patch di sicurezza Adobe di luglio e agosto 2026 completamente applicate, ovvero il livello di aggiornamento massimo disponibile al momento dell'attacco. Come ha dichiarato Disrex a The Hacker News: "Patch status was irrelevant here, which is the part merchants most need to hear".

"Sansec is publishing early because stores are being compromised right now"

Sansec ha riprodotto con successo la catena di attacco completa su installazioni pulite di Magento Open Source 2.4.7, 2.4.8 e 2.4.9. Un secondo store gestito da Disrex risultava addirittura a otto livelli di patch di sicurezza di distanza dalla versione corrente (2.4.7-p2 contro 2.4.7-p10), confermando che né lo stato aggiornato né quello obsoleto costituiscono fattore discriminante per la vulnerabilità.

Adobe non ha pubblicato advisory, CVE, patch o workaround al 6 settembre 2026. La prossima release di sicurezza programmata è fissata per l'8 settembre 2026, senza conferma che includerà un fix per StyleSmuggler. Il silenzio istituzionale contrasta con la risposta frammentata della community: Sansec ha rilasciato regole di blocco per la propria piattaforma Shield, mentre Disrex, ProxiBlue e Graycore hanno pubblicato patch non ufficiali di hardening.

Perché è importante

La fonte non specifica misure correttive ufficiali né workarounds convalidati da Adobe. Il dossier non documenta la natura esatta dei dati accessibili tramite Redis locale né conferma se l'implant abbia funzionalità di data exfiltration, skimming di pagamento o creazione di account amministrativi rogue in tutti i casi. Disrex non ha rilevato skimmer, exfiltration o account amministrativi compromessi nei due store da essa gestiti, ma questo dato si riferisce a un campione limitato.

Non emergono sovrapposizioni infrastrutturali che colleghino l'attore a campagne note allo stato attuale. L'origine degli attaccanti, il movente e lo scopo finale dell'operazione restano indeterminati. Sansec non ha dichiarato un numero totale di store compromessi.

La vulnerabilità pone un problema strutturale per l'ecosistema Magento: GraphQL è componente architetturale obbligatoria per storefront headless e Progressive Web Application, che rappresentano una quota crescente delle implementazioni moderne. La disabilitazione temporanea consigliata da Sansec per store "non headless/PWA" non è applicabile a questa porzione di installazioni, lasciando un sottoinsieme di merchant senza opzione di mitigazione che non comporti degrado funzionale.

La finestra temporale tra prima exploitation osservata e disponibilità di difese di qualsiasi tipo è stata di circa otto ore. I tempi di contenimento documentati da Disrex per i due store compromessi sono stati di circa 11-14 ore dal primo contatto. Questi intervalli, misurati su operatori con capacità incident-response attiva, indicano la velocità dell'evento rispetto alla capacità reattiva tipica del settore.

Le varianti operative osservate

L'analisi forense condotta da Disrex su tre store — due compromessi e uno attaccato ma non violato — ha evidenziato differenze significative rispetto al modello iniziale proposto da Sansec. Oltre al percorso di iniezione alternativo (system.log anziché report/), emerge la variabilità del comportamento di rete dell'implant. La connessione esclusiva a Redis locale invece che a C2 esterni rappresenta un pattern operativo che sfida le ipotesi standard di rilevamento basate su analisi del traffico outbound.

Il repository di incident response pubblicato da Disrex il 5 settembre 2026 — autodescritto come "written with AI assistance, during a live incident, in a few hours" — documenta tecniche di contenimento e forense applicate in tempo reale. La rapidità di pubblicazione riflette la pressione operativa e l'assenza di coordinate da parte del vendor ufficiale.

Il caso di Store A, cliente Sansec Shield con modulo installato, abilitato e licenziato, violato alle 23:10 UTC del 4 settembre, illustra i limiti temporali della difesa reattiva: le prime regole di blocco di Sansec sono entrate in funzione ore dopo l'attacco, non prima.

Il quadro attuale per i merchant

Al 6 settembre 2026, i merchant Magento operano in una condizione di rischio documentato ma non mitigabile attraverso i canali ufficiali. La mancanza di CVE, advisory o comunicazione Adobe lascia i team di sicurezza senza parametri formali per la classificazione del rischio e la documentazione di compliance. Le patch non ufficiali della community, pur rappresentando un'alternativa operativa, non dispongono dello stesso livello di test e garanzia di una release vendor.

Il problema si estende ai provider di hosting gestito, che devono attivare protocolli di incident response proattivo su infrastrutture che non possono proteggere tramite aggiornamento. La situazione espone la fragilità del modello di sicurezza e-commerce basato esclusivamente sulla tempestività del patching vendor, quando la velocità degli attaccanti supera quella del ciclo di rilascio anche nelle fasi di disclosure responsabile accelerate.

Le informazioni sono basate sulla fonte citata e aggiornate al momento della pubblicazione.

Fonti

Fonti e riferimenti

Ricevi DeafLetter