StyleSmuggler e gli ultimi attacchi ai negozi Magento: come operano gli hacker e come ridurre il rischio

7 settembre 2026 9 min di lettura 2 visualizzazioni

Gli ultimi giorni hanno mostrato qualcosa che gli amministratori dei negozi online sanno da tempo, ma che è facile ignorare nella manutenzione quotidiana: un sistema aggiornato non significa sempre un sistema sicuro. Quando compare una vulnerabilità 0-day, gli attaccanti non aspettano un comunicato ufficiale del produttore, un numero CVE ordinato e una finestra comoda per applicare la patch. I bot scandagliano internet, cercano endpoint vulnerabili e provano a installare un accesso persistente più velocemente di quanto la maggior parte delle aziende riesca a convocare una riunione.

È proprio questo il caso di StyleSmuggler, una vulnerabilità sfruttata attivamente e segnalata da Sansec il 5 settembre 2026. Secondo Sansec, gli attacchi sono iniziati il 4 settembre e riguardano Magento Open Source e Adobe Commerce. L’informazione più importante per i proprietari di negozi è brutale: la vulnerabilità è stata osservata anche su installazioni considerate completamente aggiornate.

Questo testo non è una guida all’attacco. È un riepilogo pratico di come appare oggi una compromissione di un negozio e-commerce e di cosa si può fare qui e ora, prima che venga pubblicata o confermata una patch ufficiale del produttore.

Che cosa è successo?

StyleSmuggler viene descritta come una RCE non autorizzata, cioè la possibilità di eseguire codice sul server senza accedere al pannello di amministrazione. In parole semplici: l’attaccante non ha bisogno della password dell’admin, di un account dipendente compromesso né dell’accesso SSH. Basta un’applicazione vulnerabile esposta su internet.

Secondo le analisi pubbliche, l’attacco si compone di più fasi:

L’attaccante invia a Magento una richiesta appositamente preparata, sfruttando l’endpoint GraphQL.
Il codice malevolo finisce in un punto che Magento successivamente elabora autonomamente.
L’applicazione esegue il codice durante il normale meccanismo di gestione delle e-mail, tra l’altro nello scenario di errore di pagamento.
Sul server viene installata una backdoor, cioè un meccanismo persistente di rientro.

È un modello particolarmente pericoloso, perché non richiede che un dipendente clicchi su un link né che un tentativo di login abbia successo. Il negozio può essere attaccato solo perché è accessibile pubblicamente.

Come operano oggi gli hacker?

Le intrusioni nei negozi online assomigliano sempre meno all’hacking manuale di un singolo obiettivo. Più spesso somigliano a una campagna automatizzata:

scansione di internet alla ricerca di uno specifico endpoint,
invio di tentativi già pronti di sfruttamento della vulnerabilità,
installazione di un processo che si maschera da elemento legittimo del sistema,
mantenimento dell’accesso tramite cron o un altro meccanismo di avvio automatico,
raccolta di sessioni, segreti, chiavi API o dati di pagamento,
eventuale installazione aggiuntiva di una webshell, di uno skimmer o di un’ulteriore backdoor.

Nel caso di StyleSmuggler sono particolarmente importanti due dettagli. Primo, la backdoor può trovarsi fuori dalla directory del negozio, quindi un semplice controllo dei file Magento non è sufficiente. Secondo, il processo può fingersi un elemento di sistema, ad esempio con un nome simile a kworker, fc-cache o chronyd. A un occhio inesperto può sembrare innocuo, ma se è eseguito dall’utente web dovrebbe far scattare un campanello d’allarme.

Perché il solo patch level non basta?

Con una vulnerabilità ordinaria la risposta è semplice: controlliamo la versione, aggiorniamo e chiudiamo la questione. Con uno 0-day la situazione è diversa. Per un certo periodo la vulnerabilità viene sfruttata prima che il produttore pubblichi una correzione o prima che la correzione venga collegata in modo inequivocabile a uno specifico attacco.

Per questo, dopo un incidente del genere, bisogna separare due domande:

il negozio è ancora vulnerabile?
il negozio è già stato compromesso in precedenza?

Non è la stessa cosa. Un WAF, il blocco di GraphQL o una patch successiva possono limitare ulteriori tentativi, ma non rimuovono automaticamente una backdoor che potrebbe essere stata installata prima.

Che cosa fare subito?

1. Limita o disattiva temporaneamente GraphQL

Se il negozio non utilizza GraphQL, la decisione più semplice è bloccare temporaneamente /graphql fino a una patch confermata. Molti negozi Magento classici, inclusi molti progetti basati su Hyvä, non hanno bisogno di GraphQL pubblico per il funzionamento del frontend. La situazione è diversa nei negozi headless e PWA: in quel caso il blocco può fermare le vendite, quindi bisogna applicare regole WAF più precise o limitazioni del traffico.

Esempio di direzione per nginx:

map $uri $gql_block { default 0; ~*^/+(index\.php/+)?graphql(\.php)?(/|$) 1;}

In ogni vhost Magento, prima degli altri location:

if ($gql_block) { return 403;}

Dopo la modifica della configurazione:

nginx -t && systemctl reload nginx

Se davanti al negozio opera Varnish, vale la pena svuotare anche la cache:

varnishadm ban 'req.url ~ .'

Dopo l’implementazione bisogna controllare diverse varianti del percorso, non solo il percorso ideale /graphql. Il test dovrebbe includere, tra gli altri, /graphql, /GraphQL, /graphql/, /graphql.php, /index.php/graphql e varianti con doppie slash. Il risultato atteso per GraphQL è 403, mentre per la home page del negozio una risposta normale, ad esempio 200.

2. Blocca il vettore noto `styles[...]`

Se non puoi disattivare tutto GraphQL, applica almeno regole che blocchino il parametro osservato styles[...] nella query string e i pattern post-sfruttamento noti.

Per nginx si possono usare regole in questa direzione:

if ($query_string ~* 'styles(\[|%5[bB])') { return 403;}if ($request_uri ~* '/paypal/transparent/response/.*(eval|base64_decode|%3[cC]%3[fF])') { return 403;}if ($request_uri ~* '%3[cC]%3[fF]|<\?') { return 403;}

Per Apache un meccanismo analogo può basarsi su mod_rewrite, bloccando le occorrenze grezze e codificate di styles[ e i tentativi di introdurre un tag PHP nell’URL.

Avvertenza importante: queste regole vedono l’URL e la query string. Se una variante dell’attacco sposta l’intero payload nel body della richiesta POST, la sola regola del server web potrebbe non bastare. In quel caso serve un WAF che analizzi il body, ModSecurity, una soluzione come Sansec Shield oppure la disattivazione temporanea di GraphQL.

3. Verifica che il negozio non sia già stato compromesso

Bloccare ulteriori tentativi è solo metà del lavoro. L’altra metà consiste nel verificare se l’attacco ha già avuto il tempo di lasciare tracce.

Esegui il controllo come utente di sistema Magento:

crontab -l | grep -i gvfsdls -la ~/.local/share/.gvfsd/ ~/.cache/fontconfig/fc-cache /tmp/.kw_* /tmp/.cache_* /tmp/.gvfsd-* /tmp/.fc-*/fc-cache /tmp/fc-cache 2>/dev/nullps -eo pid,comm,args | grep -iE 'kworker|fc-cache|chronyd'grep -ril 'x_trace_' var/report/

Presta particolare attenzione a:

file in ~/.local/share/.gvfsd/,
file fc-cache in posizioni insolite,
directory temporanee di tipo /tmp/.kw_*, /tmp/.cache_*, /tmp/.fc-*,
voci cron eseguite ogni pochi minuti,
processi che si mascherano da processi di sistema, ma che girano come utente del negozio,
file PHP in pub/media, dove normalmente non dovrebbero esserci.

Esempio di controllo rapido delle webshell:

find pub/media -name '*.php' -print

Se il risultato non è vuoto, bisogna trattarlo come un incidente, non come una piccola anomalia cosmetica.

4. Controlla i log di accesso

Nei log cerca tentativi diretti contro GraphQL e richieste insolite verso i percorsi di pagamento. La sola presenza di una richiesta sospetta non significa sempre che la compromissione sia riuscita, ma indica che il negozio è stato un bersaglio.

In pratica vale la pena controllare:

richieste POST a /graphql con parametri insoliti,
occorrenze di styles[ e della forma codificata styles%5B,
richieste a /paypal/transparent/response/ con frammenti sospetti,
serie improvvise di richieste da molti indirizzi IP,
traffico da indirizzi noti dagli IOC pubblici.

Nei materiali di lavoro compaiono tra gli altri questi IOC: 185.157.160.251, 99.84.67.186, windwsecurity.run, ntp.timesync.to. Tuttavia, non bisogna limitare la difesa solo a questi valori. Secondo le descrizioni degli incidenti, una parte del traffico proveniva da un pool più ampio di indirizzi e da infrastruttura intermediaria.

5. Prima metti al sicuro le prove, poi ripulisci

È un errore frequente: l’amministratore vede un processo sospetto, lo termina, elimina i file e solo dopo inizia l’analisi. Con una backdoor ben scritta questo può distruggere le tracce più importanti e a volte perfino rendere più difficile recuperare il campione.

L’ordine dovrebbe essere più conservativo:

Metti al sicuro i log di nginx/Apache, PHP-FPM, di sistema, Magento e cron.
Salva l’elenco dei processi, dei file aperti e delle connessioni di rete.
Crea una copia dei file sospetti per l’analisi.
Rimuovi le voci cron responsabili della ricreazione del processo.
Solo dopo interrompi i processi e rimuovi i meccanismi di persistenza.
Forza il logout delle sessioni di utenti e amministratori.
Ruota i segreti: crypt/key, password degli admin, chiavi API di pagamenti, integrazioni, SMTP, ERP, PIM e marketplace.

Se il negozio elabora pagamenti o dati dei clienti, dopo una compromissione confermata bisogna trattare la situazione come un incidente di sicurezza completo, non come una semplice rimozione di un virus.

Alcune regole che riducono davvero il rischio

Riduci al minimo la superficie di attacco pubblica

Gli endpoint che il negozio non usa non dovrebbero essere accessibili pubblicamente. Questo vale per GraphQL, pannelli di amministrazione, ambienti staging, vecchi domini demo e copie dimenticate del negozio. Nell’e-commerce molto spesso non cede la produzione, ma un vecchio staging con un database reale e gli stessi segreti.

Separa ambienti e permessi

Il processo Magento non dovrebbe avere più accessi di quelli necessari. Assenza di sudo, un account di sistema separato per ogni negozio, separazione di Redis, database separati e comunicazione in uscita limitata possono trasformare la compromissione di un negozio in un incidente circoscritto invece che in una catastrofe per l’intera infrastruttura.

Monitora processi, cron e file fuori dal webroot

La scansione della sola directory Magento non basta. La backdoor può risiedere nella home directory dell’utente, in /tmp, nella cache dei font o in un altro punto accessibile al processo dell’applicazione. Il monitoraggio dovrebbe includere:

nuove voci cron,
processi insoliti sotto l’utente web,
nuovi file eseguibili nelle directory temporanee,
connessioni a Redis, database e internet,
modifiche in app/etc/env.php,
nuovi account amministratore.

Aggiorna, ma non confondere l’aggiornamento con l’analisi dell’incidente

Quando Adobe pubblica una patch, bisogna implementarla. Ma dopo un attacco 0-day la sola applicazione della patch non risponde alla domanda se qualcuno fosse già dentro. Per questo, dopo la patch bisogna comunque effettuare il controllo di IOC, log, sessioni e segreti.

Prepara regole di emergenza già pronte

Vale la pena avere nel repository o nella documentazione operativa frammenti pronti per nginx, Apache, Varnish e WAF. In una crisi non c’è tempo per scrivere regole da zero. È buona pratica anche testare i blocchi sullo staging prima che servano in produzione.

Che cosa dovrebbe fare oggi il proprietario di un negozio?

Se gestisci Magento o Adobe Commerce, esegui almeno questi passaggi:

Crea un elenco di tutte le istanze: produzione, staging, demo, copie di lavoro.
Verifica dove GraphQL è pubblico e se è davvero necessario.
Implementa un blocco temporaneo di GraphQL oppure regole che blocchino styles[...].
Verifica il blocco con test HTTP.
Esamina il server alla ricerca di processi, cron, file e log che indichino StyleSmuggler.
Se trovi IOC, metti al sicuro le prove e tratta la situazione come un incidente.
Dopo la patch ufficiale del produttore, aggiorna ogni istanza, inclusi staging e vecchie copie.
Dopo l’aggiornamento, esegui un nuovo controllo e la rotazione dei segreti, se il negozio potrebbe essere stato compromesso.

La decisione peggiore è aspettare che la situazione si chiarisca. Con uno 0-day sfruttato attivamente, il tempo gioca a favore dell’attaccante. Anche un blocco temporaneo, se ben testato e implementato consapevolmente, può far guadagnare ore preziose.

Riepilogo

StyleSmuggler è un buon esempio del rischio moderno nell’e-commerce: l’attacco non inizia dal pannello admin, ma da un endpoint pubblico; non finisce con un singolo file nella directory del negozio, ma con un processo persistente fuori dal webroot; e il patch level aggiornato non dà automaticamente una risposta sul fatto che il negozio fosse sicuro nella finestra di attacco.

Anche la difesa deve essere pratica: ridurre la superficie, bloccare il vettore noto, verificare la compromissione, mettere al sicuro le prove, ruotare i segreti e solo allora considerare la situazione sotto controllo.

In queste situazioni non vince chi ha la policy di sicurezza più elegante, ma chi dispone di procedure pronte, log, separazione degli ambienti e possibilità di implementare rapidamente regole di emergenza senza fermare l’intero business.

Fonti e materiali

Sansec: https://sansec.io/research/stylesmuggler-0day
The Hacker News: https://thehackernews.com/2026/09/unpatched-magento-and-adobe-commerce.html
Adobe Security Bulletin per Adobe Commerce: https://helpx.adobe.com/security/products/magento/apsb26-138.html