StyleSmuggler installa backdoor zero-day su negozi Magento completamente aggiornati

Gli attaccanti stanno sfruttando una vulnerabilità non corretta di Magento Open Source per eseguire codice da remoto senza autenticazione e installare una backdoor persistente su Linux. Anche Adobe Commerce potrebbe essere esposto, sebbene il prodotto non sia ancora stato sottoposto a verifiche conclusive.

La società olandese di sicurezza per l’e-commerce Sansec ha denominato la falla StyleSmuggler e ha reso nota la campagna il 5 settembre 2026, dopo aver osservato i primi attacchi il 4 settembre. Indagini indipendenti condotte da Disrex Group hanno confermato due compromissioni riuscite e un tentativo di intrusione.

Al 6 settembre, Adobe non aveva pubblicato alcun avviso, identificativo CVE, aggiornamento correttivo o workaround ufficiale. L’indice dei bollettini di sicurezza di Commerce non veniva aggiornato dall’11 agosto.

Le versioni attuali di Magento sono esposte

Sansec ha riprodotto l’intera catena di exploit senza autenticazione su installazioni pulite di Magento Open Source:

• 2.4.7
• 2.4.8
• 2.4.9

Secondo la società, tutte le versioni attuali di Magento sono interessate, compresa la 2.4.9.

La prima vittima identificata utilizzava Magento Open Source 2.4.6-p15, con gli aggiornamenti di sicurezza Adobe di luglio e agosto 2026 già installati. Adobe identifica il livello di patch di quella linea come 2.4.6-2026-aug, l’ultimo disponibile per il ramo 2.4.6.

Disrex ha analizzato separatamente un negozio compromesso con la versione 2.4.8 e un altro che utilizzava la 2.4.7-p2. Quest’ultimo era indietro di otto livelli di patch rispetto all’allora versione corrente 2.4.7-p10, ma lo stato degli aggiornamenti non ha determinato l’esito: entrambi i sistemi sono stati violati.

L’ambito dei prodotti interessati oltre Magento Open Source resta incerto. Sansec non ha pubblicato una riproduzione riuscita dell’attacco contro Adobe Commerce o Adobe Commerce on Cloud, e Adobe non ha confermato quali versioni siano vulnerabili.

La prossima pubblicazione programmata di aggiornamenti di sicurezza da parte di Adobe è prevista per l’8 settembre, ma non è noto se includerà una correzione per StyleSmuggler. Al 6 settembre non risultavano inserimenti nell’elenco CISA Known Exploited Vulnerabilities né relative scadenze per la risoluzione.

La visualizzazione di email malevole completa la catena d’attacco

StyleSmuggler utilizza due fasi per trasformare i dati scritti durante le normali operazioni di Magento in codice PHP eseguibile.

Per prima cosa, l’attaccante inserisce codice PHP in un file che Magento può creare o aggiornare, ad esempio un file dei report sugli errori. In seguito attiva l’email standard di Magento “Payment Transaction Failed Reminder”, facendo sì che la piattaforma elabori il file manipolato durante la generazione del messaggio.

Il destinatario non deve aprire l’email. Il codice può essere eseguito anche se la consegna non va a buon fine.

Un aumento insolito dei promemoria relativi ai pagamenti non riusciti dovrebbe quindi essere analizzato, anche se questi messaggi possono essere generati anche da transazioni legittimamente rifiutate.

L’analisi del codice sorgente condotta da Disrex indica che una direttiva iniettata richiama classi di Magento associate al compilatore a riga di comando per la dependency injection. La sequenza risultante incorpora un percorso di file scelto dall’attaccante, che punta al file manipolato pochi istanti prima.

Gli investigatori hanno ricondotto il presunto endpoint a tre file nella directory:

setup/src/Magento/Setup/Module/Di/Code/

Sansec non ha confermato questa interpretazione, mentre Disrex non ha pubblicato la richiesta malevola completa. Restano inoltre inedite l’intera catena di exploit, l’analisi del dropper e quella dell’impianto.

Quando l’esecuzione del codice va a buon fine, un dropper PHP tenta in sequenza sei funzioni per la creazione di processi. Successivamente scarica e avvia la backdoor.

L’impianto si nasconde come processo di lavoro del kernel Linux

Il malware viene eseguito in background con il nome di processo ingannevole:

[kworker/u:8:0]

Questa etichetta imita quella di un thread del kernel Linux. Tuttavia, un vero processo di lavoro del kernel appartiene a root e non dispone di memoria residente nello spazio utente. Un processo kworker tra parentesi quadre, eseguito dall’account del sito Magento e con consumo di memoria, è altamente sospetto.

L’impianto imposta la propria riga di comando sul nome tra parentesi quadre; di conseguenza, i sistemi di rilevamento basati esclusivamente sul campo comm del processo potrebbero non individuarlo.

Il payload principale si trova al di fuori della web root:

~/.local/share/.gvfsd/gvfsd-user

Disrex ha descritto il payload come un eseguibile Rust stripped e collegato staticamente, di circa 1,9 MB, con build per x86-64 e arm64. La persistenza viene ottenuta tramite un’entry cron che lo riavvia ogni cinque minuti:

*/5 * * * * exec <home>/.local/share/.gvfsd/gvfsd-user

Una seconda variante avvia un payload da /tmp/.kw_.

Invece di sostituire il crontab tramite il comando consueto, il malware scrive direttamente in:

/var/spool/cron/crontabs/

Questa tecnica evita di generare nei log di sistema il consueto evento di sostituzione del crontab. In un negozio compromesso era presente la stessa riga malevola 1.728 volte, e l’impianto la ripristinava entro un secondo dalla rimozione.

Altri percorsi rilevanti includono:

~/.local/share/.gvfsd/.gvfsd_<8hex>.lock
/tmp/.gvfsd_<8hex>.lock
/tmp/.kw_<random><random>

Su un sistema, l’eseguibile in esecuzione era diverso dal payload salvato su disco. Chi interviene sulla compromissione dovrebbe quindi calcolare l’hash sia del file sia dell’eseguibile mappato tramite:

/proc/<pid>/exe

Due negozi sono stati violati prima dell’arrivo delle difese

Disrex, che gestisce servizi di hosting Magento con il marchio RexHosting, ha confermato due compromissioni su account cliente isolati.

Il primo negozio interessato utilizzava Magento Open Source 2.4.8 ed è stato attaccato alle 23:10 UTC del 4 settembre. Sansec Shield era installato, attivo e bloccava altro traffico malevolo, ma le regole specifiche per StyleSmuggler non erano ancora disponibili.

Un secondo negozio, che utilizzava la 2.4.7-p2, è stato attaccato per la prima volta alle 00:55 UTC del 5 settembre. Non era un cliente Shield. Disrex ha utilizzato le evidenze recuperate da questo sistema per sviluppare l’analisi tecnica e le regole per il web server.

Le due compromissioni si sono verificate nell’arco di circa otto ore tra la prima attività osservata della campagna e la disponibilità di protezioni dedicate.

Gli account interessati avevano ciascuno un solo proprietario del sito, nessun accesso sudo e nessun percorso verso gli ambienti degli altri clienti. Il processo malevolo veniva eseguito dall’utente non privilegiato del sito. Disrex non ha rilevato movimenti laterali né la compromissione di altri siti ospitati.

Entrambi i negozi sono stati messi in sicurezza il giorno della scoperta, circa undici e quattordici ore dopo il primo contatto. Le sessioni sono state invalidate e, in via precauzionale, è stata avviata la rotazione delle credenziali.

Gli investigatori non hanno trovato prove di:

• Dati sottratti
• Skimmer per carte di pagamento
• Account amministrativi abusivi
• Backdoor nel database
• Movimenti laterali
• Compromissione di siti adiacenti

Non è noto quanti siano i negozi interessati al di fuori di queste indagini.

Il rilevamento deve estendersi oltre la web root

Il controllo di rilevamento iniziale di Sansec cerca var/report/ alla ricerca di:

X_TRACE_

Questa ricerca, da sola, non è sufficiente. In entrambe le infezioni esaminate da Disrex, l’attaccante aveva invece manipolato:

var/log/system.log

Anche il marker è cambiato nel corso della campagna. Le richieste iniziali utilizzavano un header in stile X-TRACE- seguito da dieci caratteri esadecimali; il traffico successivo ometteva la parola TRACE. Le regole di rilevamento dovrebbero quindi riconoscere la struttura più ampia, anziché una singola stringa fissa.

Un TypeError in cui array_merge() riceve un intero subito dopo l’operazione di inclusione pertinente indica che l’exploit è andato a buon fine. Non è però un comportamento universale: una variante più discreta restituisce un array vuoto e non lascia errori equivalenti.

Gli indicatori SHA-256 pubblicati includono:

e315687a1dfe61ef4a5a5642214db6d3b2b05d81391285eebc2af664641a26a7
8334b434fa3fe9f59cebe9609b11e0b1fd19d10212c45c705adec1902a1d06ef
251fabd50d7b18a8b5e1b3ef5d64e7198c17244778f6461fb1ab07f6169bf220

Gli indicatori di rete sono:

247.cdnflare[.]xyz
99.84.67[.]186:443
88.216.72[.]181
5.181.86[.]133

L’assenza di traffico esterno non dimostra che un sistema sia pulito. Un impianto, ad esempio, non ha effettuato connessioni in uscita osservabili, ma ha aperto 28 connessioni al servizio Redis del negozio sulla porta 6379 e ha avuto accesso ai dati delle sessioni Magento.

Le scansioni limitate alla web root possono inoltre creare un falso senso di sicurezza. In un negozio compromesso lo scanner aveva restituito un risultato pulito, mentre la directory home conteneva il payload e 1.728 entry cron malevole.

Cosa devono fare ora gli operatori Magento

In assenza di una patch ufficiale, gli operatori devono combinare una riduzione temporanea dell’esposizione con verifiche forensi a livello di account.

Sansec raccomanda di disabilitare temporaneamente GraphQL nei negozi che non dispongono della protezione Shield. Questa misura potrebbe essere impraticabile per i negozi headless e per quelli basati su progressive web application, che dipendono da GraphQL, mentre le implementazioni classiche e Hyvä generalmente non lo utilizzano.

Disrex, ProxiBlue e Graycore hanno pubblicato mitigazioni non ufficiali. La patch al codice sorgente di Disrex impedisce l’esecuzione tramite HTTP di tre metodi dello scanner della dependency injection, limitandoli all’esecuzione da riga di comando. Secondo quanto riferito, la versione composer-patches si applica a Magento dalla 2.4.6 alla 2.4.9 e resta attiva anche dopo i deployment tramite Composer.

Gli amministratori dovrebbero verificare prima la compatibilità. Il pacchetto di terze parti mageplaza/module-admin-permissions richiama ClassesScanner.php tramite HTTP; di conseguenza, il controllo può rendere inutilizzabile la relativa interfaccia amministrativa.

Le regole pubblicate per nginx e Apache bloccano i parametri utilizzati negli attacchi osservati, ma solo quando compaiono nella query string. Parametri equivalenti presenti nei body POST o JSON continuano a raggiungere PHP. Queste regole interrompono la campagna attuale, ma non correggono la vulnerabilità.

Chi risponde agli incidenti dovrebbe esaminare l’intero account di hosting, comprese le directory home degli utenti, /tmp, i file dello spool cron, var/report/ e var/log/system.log. Dovrebbe inoltre analizzare i processi in esecuzione tramite /proc, confrontare gli hash della memoria e del disco, invalidare le sessioni Magento e ruotare le credenziali.

Una scansione pulita del negozio non è sufficiente. Né lo è rimuovere il binario visibile senza terminare il processo ed eliminare la relativa persistenza nel cron.