Dal 4 settembre 2026 gli e-commerce basati su Magento Open Source e Adobe Commerce sono sotto attacco attivo tramite una falla che, al momento in cui scriviamo, non ha ancora una patch ufficiale, né un identificativo CVE. La vulnerabilità è stata battezzata StyleSmuggler dalla società olandese Sansec, specializzata in sicurezza delle piattaforme di commercio elettronico, che l'ha resa pubblica il 5 settembre dopo aver osservato le prime compromissioni in rete.

Il quadro è insolitamente sfavorevole per chi difende: exploit funzionante già in circolazione, nessun aggiornamento da installare, e tutte le versioni attualmente supportate risultano vulnerabili.

I fatti verificati

  • Prodotti colpiti: Magento Open Source e Adobe Commerce, tutte le versioni correnti. Sansec dichiara di aver riprodotto l'intera catena di sfruttamento non autenticata su installazioni pulite di 2.4.7, 2.4.8 e 2.4.9, cioè anche sull'ultima release disponibile.
  • Livello di patch non sufficiente: la prima vittima osservata girava su 2.4.6-p15 con gli aggiornamenti di sicurezza Adobe di luglio e agosto 2026 già applicati. Essere aggiornati non ha protetto.
  • Autenticazione richiesta: nessuna. Si tratta di una esecuzione di codice remoto pre-autenticazione, il caso peggiore per un servizio esposto su Internet.
  • Sfruttamento attivo: sì, confermato dal 4 settembre.
  • Stato del fornitore: al 6 settembre Adobe non aveva pubblicato né advisory, né CVE, né workaround ufficiale. Il prossimo rilascio di sicurezza programmato è l'8 settembre, ma non c'è conferma che includa una correzione per questa falla.

Come funziona l'attacco

La catena descritta da Sansec sfrutta il motore di template di Magento e si articola in due fasi. Nella prima l'attaccante inietta codice PHP provocando deliberatamente la generazione di un report di errore; nella seconda induce Magento a eseguire quel codice nel momento in cui il sistema renderizza l'email di sollecito per una transazione di pagamento fallita ("Payment Transaction Failed Reminder"). Il nome StyleSmuggler deriva dall'uso di proprietà di stile per far passare il payload attraverso i controlli di sanificazione esistenti.

È un meccanismo che merita attenzione anche al di là del caso specifico: l'esecuzione avviene in un flusso asincrono e legittimo del gestionale, non nella richiesta HTTP dell'attaccante. Chi cerca l'attacco solo nei log del web server rischia di non vedere nulla.

Il payload

Le compromissioni osservate installano una backdoor persistente: un binario Rust compilato staticamente, circa 1,9 MB, disponibile per architetture x86-64 e ARM64, mascherato da thread del kernel Linux con il nome [kworker/u:8:0] e riavviato ogni cinque minuti tramite una voce di cron. La scelta di un binario statico e di un nome plausibile in ps indica un avversario preparato, non uno script kiddie che passa di lì.

Cosa significa per le aziende italiane

Magento resta una piattaforma molto diffusa nel commercio elettronico italiano di fascia media e medio-alta: negozi con cataloghi complessi, gestiti tipicamente da web agency o system integrator esterni, spesso su hosting dedicato o cloud gestito. Questa configurazione produce due rischi tipicamente italiani.

Il primo è il vuoto di responsabilità. In molti contratti tra merchant e agenzia l'aggiornamento di Magento è previsto, ma la risposta a un incidente fuori dal ciclo delle patch — cioè esattamente questo scenario — non lo è. Nelle prossime ore la domanda pratica non è "chi installa la patch" (non c'è), ma "chi mette le regole di mitigazione sul web server, questa sera". Se il contratto non lo dice, va deciso ora per telefono, non fra due settimane via ticket.

Il secondo è la natura del dato trattato. Un e-commerce compromesso a livello di codice server permette due cose molto diverse tra loro: esfiltrare l'archivio ordini (nomi, indirizzi, email, telefoni, storico acquisti) e iniettare skimmer che catturano i dati di pagamento digitati dal cliente al checkout. La seconda ipotesi trasforma l'incidente in un problema PCI DSS oltre che GDPR, e coinvolge il gestore dei pagamenti.

Sul piano normativo: una compromissione di questo tipo con accesso ai dati dei clienti è una violazione di dati personali ai sensi dell'art. 33 GDPR, con notifica al Garante entro 72 ore dalla conoscenza del fatto. Se viene installato uno skimmer sul checkout, il rischio per i diritti degli interessati è elevato e scatta anche la comunicazione agli interessati (art. 34). Attenzione a un punto che si sottovaluta: il termine delle 72 ore decorre da quando si viene a conoscenza della violazione, non da quando si finisce l'analisi forense. Se avete un dubbio ragionevole, aprite la pratica e integrate dopo.

Per i merchant che rientrano nel perimetro NIS2 come soggetti importanti — molti retailer di dimensioni medio-grandi lo sono, anche se non se ne sono ancora accorti — si aggiunge la notifica ad ACN tramite CSIRT Italia, con la pre-notifica entro 24 ore.

Cosa fare subito

  • Trattate ogni installazione Magento come potenzialmente compromessa, non come "da patchare". Non c'è una patch: la domanda giusta è se siete già dentro la finestra di attacco (dal 4 settembre).
  • Verificate i processi in esecuzione sul server applicativo cercando anomalie del tipo [kworker/u:8:0]: un vero kernel thread non ha un eseguibile associato. Controllate ls -l /proc/<pid>/exe per ogni processo dall'aspetto sospetto.
  • Ispezionate le crontab di tutti gli utenti, incluso quello del web server, alla ricerca di voci con frequenza di cinque minuti aggiunte di recente.
  • Disattivate l'email "Payment Transaction Failed Reminder" dalla configurazione delle vendite finché non arriva una correzione: è il vettore di esecuzione osservato.
  • Applicate regole di blocco a livello di reverse proxy o WAF sui pattern di richiesta pubblicati da Sansec, prima che il traffico arrivi all'applicazione. Sono disponibili anche mitigazioni sviluppate dalla comunità Magento, ma vanno lette e capite prima di eseguirle in produzione.
  • Confrontate il codice sorgente con un backup pulito o con il repository Git di riferimento, cercando file modificati dal 3 settembre in poi in app/, pub/ e nelle directory di template.
  • Ruotate le credenziali dell'admin Magento, del database e delle API dei gateway di pagamento se trovate anche solo un indicatore di compromissione.
  • Monitorate il checkout dal lato client: caricate una pagina di pagamento e verificate che non compaiano script di terze parti non previsti.
  • Documentate tutto per iscritto da subito: orari, verifiche fatte, esiti. Se la notifica al Garante diventa necessaria, questa cronologia è ciò che distingue una gestione difendibile da una improvvisata.

Un'ultima considerazione. Quando un fornitore non ha ancora una patch, la tentazione naturale è aspettare l'aggiornamento e non fare nulla nel frattempo. In questo caso l'attesa non è neutra: gli attaccanti stanno lavorando adesso, e ogni giorno di ritardo è un giorno in cui un binario Rust può prendere residenza sul vostro server. Le mitigazioni temporanee sono scomode e imperfette, ma sono l'unica cosa che avete fino all'8 settembre — e forse anche dopo.