StyleSmuggler colpisce Magento e Adobe Commerce: come ridurre il rischio prima della patch

StyleSmuggler è il nome attribuito da Sansec a uno zero-day segnalato come sfruttato attivamente contro Magento Open Source e Adobe Commerce. L’impatto riportato è critico: un attaccante privo di credenziali potrebbe ottenere l’esecuzione remota di codice (RCE) sul server del negozio. Secondo Sansec, gli attacchi sono iniziati il 4 settembre 2026 e la vulnerabilità è stata resa pubblica il 5 settembre. 2223

Per chi gestisce un e-commerce, il punto essenziale è questo: avere installato tutti gli aggiornamenti disponibili prima della divulgazione non basta necessariamente a proteggere un’installazione Magento esposta su Internet. Occorre ridurre subito la superficie d’attacco, verificare l’eventuale compromissione e preservare le evidenze prima di applicare mitigazioni o avviare operazioni di pulizia.

Cosa si sapeva nella prima finestra di divulgazione

Sansec ha riferito che risultavano coinvolte tutte le versioni correnti, inclusa Magento Open Source 2.4.9, e di avere riprodotto l’intera catena non autenticata su installazioni pulite di Magento Open Source 2.4.7, 2.4.8 e 2.4.9. 22 È stato inoltre riportato un caso su versione 2.4.6-p15 con gli aggiornamenti di sicurezza di luglio e agosto 2026 già applicati: un elemento che evidenzia come il regolare patching precedente non coprisse questo problema appena emerso. 32

Al 6 settembre, Adobe non aveva pubblicato un CVE specifico per StyleSmuggler, un bollettino di sicurezza, una patch o un workaround ufficiale. 23 Per Adobe Commerce as a Cloud Service era prevista una release in produzione l’8 settembre, ma il calendario della release non confermava l’inclusione di una correzione per StyleSmuggler. 8

Queste date descrivono la situazione nella fase iniziale della divulgazione. Prima di pianificare l’installazione di patch, è opportuno verificare gli ultimi bollettini e le release notes Adobe.

Come funziona la catena d’attacco segnalata

Secondo Sansec, l’attacco sfrutta le proprietà styles di input GraphQL non autenticato per aggirare controlli esistenti e iniettare PHP controllato dall’attaccante nell’elaborazione dei template Magento. La catena descritta ha due stadi:

1. il codice viene scritto in contenuti generati da Magento, per esempio un report di errore;
2. il rendering di un’email per pagamento non riuscito porta all’esecuzione del contenuto avvelenato. 22

La notifica Payment Transaction Failed è una normale funzione configurabile delle email di Adobe Commerce. 18 Nel percorso descritto, il passaggio decisivo è il rendering del template lato server: non è necessario che un destinatario apra l’email. Per questo, attività anomale relative alle notifiche di pagamento fallito possono essere rilevanti anche se l’email non viene consegnata o nessuno vi interagisce.

Le segnalazioni pubbliche descrivono, dopo l’esecuzione iniziale, un backdoor Linux persistente, con processi camuffati da componenti di sistema come kworker e persistenza ottenuta tramite cron. 2035 Sono utili piste di ricerca, ma non un elenco completo e definitivo di indicatori: nomi di file, processi, percorsi e infrastrutture di rete possono cambiare.

Le affermazioni che non sono state confermate in modo indipendente

Alcuni report di threat intelligence hanno avanzato ulteriori ipotesi: furto dei dati di sessione in Redis senza traffico visibile verso server di comando e controllo, oppure elusione delle verifiche basate su var/report/ tramite avvelenamento di var/log/system.log.

Nei materiali disponibili non figurano però un’analisi malware riproducibile né una seconda fonte forense indipendente che confermi questi comportamenti specifici. Vanno quindi trattati come informazioni di intelligence non verificate, non come fatti accertati.

L’incertezza non riduce l’urgenza dell’indagine: significa piuttosto che la raccolta delle evidenze non deve fermarsi ai report Magento. Vanno inclusi log del sistema operativo, processi, cron, server web, PHP-FPM, Redis, DNS e firewall.

Le priorità immediate per il contenimento

1. Limitare l’esposizione pubblica di GraphQL

Se il negozio può funzionare senza GraphQL pubblico, disabilitare o bloccare temporaneamente /graphql. Se GraphQL è indispensabile, limitarne l’accesso tramite CDN, WAF o reverse proxy ai soli client, alle operazioni e ai pattern di query strettamente necessari. Sansec ha indicato la disabilitazione di GraphQL come controllo immediato in assenza di una correzione ufficiale. 22

È una misura compensativa, non la dimostrazione che il server non sia già stato compromesso.

2. Valutare con cautela mitigazioni d’emergenza

Sansec ha dichiarato che le proprie regole Shield bloccano entrambe le fasi note dell’attacco. 22 Disrex ha inoltre comunicato la disponibilità di patch di mitigazione d’emergenza per bloccare la catena conosciuta, specificando però che tali patch non rimuovono un’infezione già presente. 35

Qualunque patch di terze parti o regola WAF va revisionata, testata in staging e distribuita con una procedura di change management controllata. Va mantenuta finché la correzione Adobe non sia stata testata e verificata sul percorso d’attacco pertinente.

3. Conservare le evidenze prima di pulire o riavviare

Se esiste anche solo il sospetto di compromissione, acquisire i log rilevanti e un’istantanea dell’host e dei processi prima di cancellare file o riavviare servizi. Le verifiche dovrebbero includere:

• richieste al web server e al reverse proxy verso /graphql, soprattutto POST anomali che contengano styles;
• log di PHP-FPM, applicazione, cron, account di servizio, DNS e firewall;
• volumi insoliti di email per pagamenti non riusciti o attività atipiche di rendering dei template;
• job cron nuovi o modificati, in particolare comandi eseguiti dall’account del servizio web;
• processi figli inattesi di PHP-FPM, processi sospetti che imitano utility di sistema e file eseguibili sconosciuti in percorsi scrivibili o nascosti;
• socket aperti e connessioni in uscita dagli account web e dal runtime PHP.

Non limitare l’analisi a var/report/ o ai soli log applicativi Magento: tali fonti possono essere incomplete anche senza manomissioni deliberate.

Ridurre l’impatto di una compromissione

Durante l’indagine, alcune misure di hardening sono utili in modo generale:

• eseguire web server e worker PHP con un account dedicato, non privilegiato e con accesso minimo al filesystem;
• rendere il codice applicativo in sola lettura per l’account di runtime, consentendo scritture soltanto nelle directory davvero necessarie a Commerce;
• impedire l’esecuzione da directory scrivibili — temporanee, cache, upload, media, log, report e generate — quando compatibile con l’operatività;
• valutare le opzioni di mount noexec, nodev e nosuid per filesystem temporanei o ad alta scrittura, dopo test di compatibilità;
• limitare il traffico in uscita dagli host applicativi a una allowlist esplicita e generare alert per attività DNS o UDP inattese;
• mantenere Redis fuori da Internet pubblico e proteggerlo con rete privata, autenticazione e controlli di trasporto adeguati;
• monitorare nuovi cron job, processi avviati in modo anomalo da PHP-FPM e modifiche agli artefatti di deployment.

Questi controlli non sostituiscono la correzione applicativa, ma possono ostacolare la persistenza e rendere più individuabili le anomalie.

Cosa fare se emergono indicatori

Un indicatore positivo va trattato come possibile compromissione completa del server. Isolare l’host coinvolto, conservare le evidenze forensi e ruotare tutte le credenziali che potrebbero essere state accessibili dall’ambiente applicativo: credenziali amministrative e di integrazione Magento, segreti API, credenziali di database e Redis, segreti di deployment e SSH, oltre alle credenziali del provider di pagamento. Dove appropriato, invalidare anche le sessioni dei clienti.

In caso di violazione confermata, ricostruire da un’immagine nota come affidabile o da un backup verificato è più sicuro che eliminare un binario visibile e rimettere in servizio lo stesso host. Una patch di mitigazione può prevenire la reinfezione, ma non dimostra che backdoor, persistenza o furto di credenziali siano stati eliminati.

In sintesi

La lezione di StyleSmuggler è che una nuova catena sfruttata attivamente può aggirare un livello di patch Magento altrimenti aggiornato. Nella fase iniziale dell’incidente, la risposta più prudente era ridurre o rimuovere l’esposizione pubblica di GraphQL, applicare protezioni temporanee verificate, cercare tracce di compromissione nell’intera telemetria dell’applicazione e dell’host, e prepararsi ad applicare e validare la remediation ufficiale Adobe quando disponibile. 222335