StyleSmuggler: nuova vulnerabilità critica per Magento 2 e Adobe Commerce
Aggiornamento: 7 settembre 2026
È stata identificata una nuova vulnerabilità critica che interessa Magento Open Source e Adobe Commerce, denominata StyleSmuggler.
La vulnerabilità è particolarmente seria perché può consentire a un attaccante di ottenere Remote Code Execution (RCE) senza autenticazione, cioè eseguire codice sul server senza conoscere credenziali Magento Admin.
Il problema non è solamente teorico.
Secondo le analisi pubblicate da Sansec, gli attacchi sono già stati osservati in ambiente reale a partire dal 4 settembre 2026.
Sono state inoltre riprodotte con successo catene di attacco su installazioni pulite di:
Magento Open Source 2.4.7
Magento Open Source 2.4.8
Magento Open Source 2.4.9
Il primo sistema compromesso analizzato dai ricercatori utilizzava inoltre Magento 2.4.6-p15 con gli aggiornamenti di sicurezza di luglio e agosto 2026 già installati.
Questo significa che avere Magento aggiornato alle patch precedentemente disponibili non è sufficiente, da solo, a escludere il rischio.
Cos’è StyleSmuggler?
StyleSmuggler sfrutta il sistema di rendering dei template di Magento.
In termini semplificati, l’attacco riesce a introdurre contenuto malevolo all’interno di dati che vengono successivamente elaborati dal sistema di template Magento.
La catena di attacco può portare all’esecuzione di codice PHP sul server.
Il problema più rilevante è che l’attaccante:
- non deve conoscere la password di Magento Admin;
- non necessita di un account cliente;
- può attaccare un Magento pubblicamente raggiungibile;
- può installare meccanismi di persistenza anche al di fuori della directory Magento.
Non siamo quindi di fronte a una semplice vulnerabilità del frontend.
Una compromissione riuscita deve essere trattata come una possibile compromissione dell’intero server.
Quali versioni Magento sono interessate?
Le informazioni disponibili al momento indicano che il problema interessa le versioni correnti di Magento Open Source e Adobe Commerce.
Sansec ha dichiarato di aver riprodotto la catena completa su:
Magento 2.4.7
Magento 2.4.8
Magento 2.4.9
ed ha rilevato il primo caso su una:
Magento 2.4.6-p15
che disponeva già delle patch precedenti.
Di conseguenza, non bisogna presumere che un Magento sia sicuro semplicemente perché:
bin/magento security:patch-status
non segnala patch mancanti.
La vulnerabilità StyleSmuggler è infatti stata scoperta dopo gli aggiornamenti precedentemente disponibili.
Perché questa vulnerabilità è particolarmente pericolosa?
Normalmente, quando viene scoperta una vulnerabilità Magento, il merchant può:
- applicare la patch;
- verificare l’integrità dell’applicazione;
- aggiornare i moduli;
- controllare i log.
Con StyleSmuggler la situazione richiede maggiore attenzione.
Gli attaccanti osservati hanno installato un processo in background progettato per sembrare un normale processo Linux.
Uno degli indicatori individuati dai ricercatori utilizza un nome simile a:
[kworker/u:8:0]
Il nome richiama intenzionalmente i normali kernel worker Linux.
Questo significa che cercare esclusivamente file PHP sospetti dentro:
app/
vendor/
pub/
generated/
può non essere sufficiente.
Una scansione Magento pulita non garantisce che il server sia pulito
Questo è probabilmente il punto più importante per merchant e responsabili ecommerce.
Dopo una compromissione, l’attaccante può installare componenti persistenti:
Magento
│
▼
Remote Code Execution
│
├──► file Magento modificati
│
├──► file temporanei
│
├──► processi Linux
│
├──► cron
│
├──► home directory
│
└──► persistence esterna al webroot
Quindi:
Un controllo limitato alla directory Magento non permette necessariamente di escludere una compromissione.
Occorre verificare anche il sistema operativo.
Cosa dovrebbe controllare immediatamente un merchant Magento?
Se il proprio ecommerce Magento è stato pubblicamente raggiungibile dal 4 settembre 2026, consigliamo di effettuare almeno una verifica dell’infrastruttura.
Il controllo dovrebbe comprendere:
Magento
+
Sistema operativo
+
Processi
+
Cron
+
Filesystem
+
Log
+
Directory temporanee
+
Account di sistema
In particolare è opportuno verificare:
- processi attualmente in esecuzione;
- cron dell’utente Magento;
- cron di sistema;
- directory
/tmp; - home directory degli utenti;
- file Magento modificati recentemente;
- file presenti in
var/report; - processi persistenti;
- connessioni di rete anomale;
- file nascosti;
- modifiche recenti al filesystem;
- eventuali nuovi utenti o chiavi SSH.
Alcuni indicatori pubblicati da Sansec
Sansec ha pubblicato alcuni indicatori utili per identificare compromissioni già avvenute.
Tra questi risultano artefatti associati a directory e processi simili a:
~/.local/share/.gvfsd/
/tmp/.kw_*
/tmp/.gvfsd-*
e processi che possono presentarsi come:
[kworker/u:8:0]
Sono stati inoltre identificati riferimenti sospetti all’interno di:
var/report/
Questi controlli sono importanti, ma l’assenza di questi indicatori non dimostra automaticamente che il server non sia stato compromesso.
Gli indicatori di compromissione possono evolvere man mano che gli attaccanti modificano strumenti e tecniche.
Attenzione alle email “Payment Transaction Failed”
Sansec ha inoltre osservato che la catena StyleSmuggler può coinvolgere il rendering della normale email Magento:
Payment Transaction Failed Reminder
Un aumento improvviso o insolito di queste notifiche può quindi rappresentare un segnale da investigare.
Naturalmente una transazione realmente fallita può produrre la stessa email.
La presenza dell’email non significa quindi automaticamente che sia avvenuto un attacco.
Analogamente, non ricevere queste email non significa che il Magento sia sicuro, perché l’esecuzione può avvenire durante il rendering del template indipendentemente dalla corretta consegna del messaggio.
Patch: qual è la situazione?
Al momento della pubblicazione di questo articolo, 7 settembre 2026, StyleSmuggler è ancora oggetto di analisi.
Sansec ha pubblicato misure temporanee di detection e mitigation.
Adobe ha programmato il prossimo security bulletin Commerce per l’8 settembre 2026, ma al momento non è possibile considerare automaticamente quel rilascio come la correzione definitiva di StyleSmuggler fino alla pubblicazione delle informazioni ufficiali.
È quindi importante distinguere tre operazioni differenti:
MITIGATION
Ridurre/bloccare la possibilità di nuovo sfruttamento
PATCH
Correggere la vulnerabilità
CLEANUP
Rimuovere una compromissione già avvenuta
Una mitigation non elimina un malware eventualmente già installato sul server.
Analogamente, applicare una futura patch Adobe non potrà automaticamente rimuovere eventuali backdoor introdotte prima dell’aggiornamento.
Applicare la patch non basta se il server è già compromesso
Questo principio vale per qualsiasi vulnerabilità RCE.
Consideriamo:
4 settembre
│
▼
attaccante entra nel server
│
▼
installa persistence
│
▼
8 settembre
│
▼
merchant applica patch
La patch può impedire che la vulnerabilità venga sfruttata nuovamente.
Ma:
Backdoor già installata
│
└────► può continuare a funzionare
Per questo, se esistono indicatori di compromissione, bisogna affrontare separatamente:
Vulnerability remediation
e:
Incident response
Magento aggiornato non significa necessariamente server sicuro
L’incidente evidenzia ancora una volta un errore piuttosto frequente nella gestione della sicurezza ecommerce:
considerare la sicurezza Magento equivalente all’aggiornamento del software Magento.
In realtà bisogna considerare almeno quattro livelli:
APPLICATION
Magento + moduli
SERVER
Linux + PHP + servizi
INFRASTRUCTURE
Firewall + networking + accessi
MONITORING
Log + processi + filesystem + anomalie
Un ecommerce può avere:
Magento aggiornato
ma essere comunque compromesso a livello:
Linux
o tramite persistence installata prima dell’applicazione di una patch.
Il rischio per un ecommerce
Una Remote Code Execution su Magento deve essere considerata una vulnerabilità critica perché un ecommerce gestisce informazioni particolarmente sensibili:
- dati personali dei clienti;
- ordini;
- indirizzi;
- account;
- integrazioni ERP;
- API;
- credenziali applicative;
- token;
- sistemi di pagamento;
- servizi cloud;
- database.
Un attaccante che ottiene accesso al server potrebbe inoltre tentare di utilizzare il Magento come punto di partenza verso altri sistemi aziendali.
Per questo StyleSmuggler non deve essere trattata semplicemente come:
"un'altra patch Magento"
ma come un possibile incidente infrastrutturale.
Cosa consigliamo ai merchant Magento
Se gestite un ecommerce Magento Open Source o Adobe Commerce pubblicamente accessibile durante questa finestra di attacco, consigliamo di procedere con questo ordine:
1. Verificare l’esposizione
Identificare:
versione Magento
patch installate
periodo di esposizione
configurazione GraphQL
infrastruttura
2. Applicare le mitigation disponibili
Ridurre immediatamente la superficie di attacco utilizzando le mitigation disponibili e mantenendole aggiornate con l’evoluzione delle indicazioni dei ricercatori e di Adobe.
3. Controllare l’intero server
Non limitarsi alla directory Magento.
Analizzare:
processi
cron
filesystem
/tmp
home directories
connessioni
log
report Magento
4. Verificare gli indicatori di compromissione
Confrontare il sistema con gli IOC pubblicati e con le informazioni più recenti disponibili.
5. Prepararsi ad applicare immediatamente la patch ufficiale
Quando Adobe renderà disponibile una correzione specifica, questa dovrà essere testata e applicata rapidamente.
6. Se viene rilevata una compromissione, trattarla come un incidente
Non limitarsi a cancellare il primo file sospetto trovato.
Occorre verificare eventuali:
backdoor
cron
processi persistenti
credenziali compromesse
chiavi
token
file modificati
e valutare la rotazione delle credenziali potenzialmente esposte.
Devlogica può verificare il tuo Magento
Se gestisci un ecommerce Magento Open Source o Adobe Commerce e non sei sicuro dello stato del tuo sistema, possiamo effettuare una verifica tecnica dell’installazione e dell’infrastruttura.
Possiamo supportarti nella verifica di:
Versione Magento e security patch
↓
Esposizione a StyleSmuggler
↓
Controllo filesystem Magento
↓
Processi e cron del server
↓
Indicatori di compromissione
↓
Log e anomalie
↓
Mitigation
↓
Piano di remediation
In presenza di anomalie possiamo inoltre supportare il team IT nell’identificazione dell’origine della compromissione e nella messa in sicurezza dell’installazione.
Se vuoi verificare rapidamente il tuo ecommerce Magento, contatta Devlogica indicando la versione Magento utilizzata e la tipologia di hosting/server.
La priorità in questo momento non è semplicemente verificare se Magento segnala di essere aggiornato.
La domanda corretta è:
possiamo dimostrare che il server non è stato compromesso?
FAQ
StyleSmuggler interessa Magento 2.4.9?
Sì. Sansec dichiara di aver riprodotto la catena di attacco completa anche su Magento Open Source 2.4.9.
Magento 2.4.8 è vulnerabile?
Sì. La vulnerabilità è stata riprodotta su Magento 2.4.8.
Magento 2.4.7 è vulnerabile?
Sì. Anche Magento 2.4.7 è stato utilizzato dai ricercatori per riprodurre la catena completa.
Se Magento è completamente aggiornato sono al sicuro?
Non necessariamente.
Il primo sistema compromesso osservato dai ricercatori utilizzava Magento 2.4.6-p15 con le security patch di luglio e agosto 2026 installate.
StyleSmuggler era una vulnerabilità non ancora corretta da quelle patch.
L’attaccante deve conoscere la password Admin?
No.
Il problema è particolarmente critico perché la catena individuata consente una Remote Code Execution senza autenticazione.
È sufficiente eseguire una scansione dei file Magento?
No.
Una compromissione può produrre processi, cron e file di persistence al di fuori della directory Magento.
Il server deve quindi essere controllato nel suo complesso.
Se applico una mitigation sono sicuro?
Una mitigation serve a bloccare o ridurre la possibilità di nuovi attacchi.
Non elimina automaticamente eventuali backdoor installate precedentemente.
Se applico la futura patch Adobe posso considerare risolto il problema?
La patch correggerà la vulnerabilità a cui sarà destinata, ma una macchina compromessa prima dell’applicazione deve comunque essere sottoposta a verifica.
Patch e incident response sono due attività differenti.
Devo spegnere immediatamente il mio ecommerce?
Non esiste una risposta valida per qualsiasi infrastruttura.
È però opportuno effettuare immediatamente una valutazione del rischio, applicare le mitigation disponibili e verificare il sistema.
In presenza di indicatori di compromissione la priorità deve diventare il contenimento dell’incidente.
Fonti
Sansec — StyleSmuggler: Magento and Adobe Commerce 0-day RCE under active attack
Analisi tecnica pubblicata il 5 settembre 2026 con versioni testate, timeline, indicatori di compromissione e prime misure di mitigation.
https://sansec.io/research/stylesmuggler
Sansec Threat Research
Pagina di ricerca e aggiornamenti sulle campagne di attacco Magento e Adobe Commerce.
Adobe Commerce Security
Bollettini di sicurezza ufficiali Adobe Commerce e Magento Open Source.
https://helpx.adobe.com/security/security-bulletin.html
Adobe Commerce — APSB26-92
Aggiornamento di sicurezza Adobe dell’11 agosto 2026, precedente alla scoperta pubblica di StyleSmuggler.
https://experienceleague.adobe.com/en/docs/experience-cloud-kcs/kbarticles/ka-40380
Nota: StyleSmuggler è un incidente in corso e le informazioni tecniche possono cambiare rapidamente. Questo articolo verrà aggiornato con la pubblicazione di ulteriori dettagli da parte di Adobe, Sansec e degli altri ricercatori coinvolti.