La sicurezza di un eCommerce Magento non può essere considerata un’attività occasionale. Aggiornamenti, security patch, controllo delle estensioni e monitoraggio dell’installazione devono far parte di un processo continuativo, soprattutto per piattaforme che gestiscono dati dei clienti, ordini, pagamenti e integrazioni con sistemi esterni.
Gli eventi che hanno interessato Magento Open Source e Adobe Commerce nel 2026 ne rappresentano un esempio concreto. Vulnerabilità critiche come PolyShell e StyleSmuggler hanno mostrato come, in alcuni casi, gli attacchi possano iniziare prima che sia disponibile una patch ufficiale e come la semplice applicazione di una correzione non sia necessariamente sufficiente se il sistema è già stato compromesso.
Per questo motivo la sicurezza di Magento deve essere affrontata attraverso una combinazione di aggiornamento, patching, monitoraggio, prevenzione e capacità di intervento.
Perché la sicurezza Magento richiede un’attività continua
Magento è una piattaforma eCommerce evoluta e altamente estensibile. Questa flessibilità consente di realizzare store complessi, integrare sistemi gestionali, marketplace, servizi di pagamento e numerose funzionalità di terze parti, ma richiede anche una gestione attenta dell’intero ecosistema applicativo.
La sicurezza non riguarda infatti soltanto il core di Magento. Deve essere considerato l’insieme formato da piattaforma, estensioni, server, servizi esterni, credenziali, configurazioni e procedure di accesso.
Mantenere un’installazione aggiornata rappresenta quindi una delle prime misure di protezione, ma non l’unica. È necessario seguire i bollettini di sicurezza, verificare le vulnerabilità pubblicate, applicare tempestivamente le patch necessarie e controllare che non siano presenti anomalie o indicatori di una possibile compromissione.
Gli eventi del 2026 mostrano chiaramente perché questo approccio sia importante.
Magento e sicurezza: cosa è successo nel 2026
Nel corso del 2026 Adobe ha pubblicato diversi aggiornamenti di sicurezza per Magento Open Source e Adobe Commerce. Tra gli episodi più significativi emergono PolyShell (CVE-2026-48356) e StyleSmuggler (CVE-2026-75650), due vulnerabilità che hanno portato a campagne di sfruttamento reali.
È importante utilizzare una terminologia corretta: PolyShell e StyleSmuggler non sono semplicemente due “virus Magento”. Sono vulnerabilità e tecniche di attacco che possono consentire a un attaccante di compromettere uno store e, successivamente, installare backdoor, web shell o altri payload malevoli.
La sequenza degli eventi è particolarmente significativa: nel caso di PolyShell gli attacchi sono stati osservati mentre non era ancora disponibile una patch ufficiale per le normali versioni production interessate; nel caso di StyleSmuggler lo sfruttamento della vulnerabilità è iniziato prima della pubblicazione dell’hotfix Adobe.
Questo evidenzia una caratteristica fondamentale della sicurezza informatica: tra la scoperta di una vulnerabilità, la disponibilità di una correzione e la sua applicazione può esistere una finestra temporale nella quale è necessario adottare misure di mitigazione e aumentare il livello di monitoraggio.
PolyShell: una vulnerabilità critica nell’API REST
Il 17 marzo 2026 Sansec ha reso pubblica PolyShell, identificata successivamente come CVE-2026-48356. La vulnerabilità interessa l’API REST di Magento e permette a un attaccante non autenticato di caricare file di tipo pericoloso aggirando i controlli attraverso file appositamente costruiti.
A seconda della configurazione dell’ambiente, lo sfruttamento della vulnerabilità può determinare conseguenze particolarmente gravi, fino alla possibilità di eseguire codice sul sistema.
Uno degli aspetti più interessanti del caso PolyShell riguarda proprio la gestione temporale della vulnerabilità. Al momento della pubblicazione dell’analisi di Sansec, non era ancora disponibile una patch Adobe ufficiale destinata alle normali versioni production interessate. La correzione era presente nella versione prerelease di Magento 2.4.9.
In questa fase diventavano quindi importanti le misure di mitigazione, la configurazione del server, eventuali protezioni a livello WAF e soprattutto il monitoraggio degli store potenzialmente esposti.
Sansec ha successivamente rilevato tentativi di sfruttamento della vulnerabilità e documentato campagne nelle quali venivano installati componenti malevoli e backdoor sugli store compromessi.
Il 12 maggio 2026 Adobe ha rilasciato Magento 2.4.9, contenente la correzione. Il successivo aggiornamento di sicurezza Adobe APSB26-73 del 14 luglio ha incluso CVE-2026-48356 tra le vulnerabilità corrette anche per le release supportate interessate, classificandola come critica.
Il caso PolyShell mostra quindi concretamente perché la gestione della sicurezza non possa dipendere esclusivamente dagli aggiornamenti programmati: in presenza di una nuova vulnerabilità critica può essere necessario intervenire prima attraverso mitigazioni e controlli specifici.
Security patch e patch isolate di Adobe
Nel 2026 Adobe ha introdotto un modello che consente di distribuire più rapidamente alcune correzioni attraverso le isolated security patches.
Si tratta di patch circoscritte che contengono il codice necessario a correggere una o più vulnerabilità specifiche, senza includere feature o modifiche non correlate alla sicurezza. L’obiettivo è permettere ai merchant di valutare, testare e applicare più rapidamente una correzione critica rispetto a un aggiornamento più ampio della piattaforma.
Le patch isolate non sono cumulative e vengono successivamente incorporate nelle normali security patch della relativa linea Magento.
Adobe specifica inoltre che, per applicare una isolated security patch, l’installazione deve trovarsi sul livello di security patch supportato previsto per quella release. Questo è un aspetto particolarmente importante: mantenere Magento regolarmente aggiornato rende più semplice intervenire rapidamente quando viene pubblicata una nuova correzione critica.
Un’installazione molto indietro rispetto alle versioni supportate può invece richiedere attività preliminari di aggiornamento e compatibilità, aumentando la complessità dell’intervento proprio nel momento in cui la rapidità è maggiormente necessaria.
StyleSmuggler: una zero-day Magento sfruttata attivamente
Un secondo episodio particolarmente significativo si è verificato nel settembre 2026 con StyleSmuggler, CVE-2026-75650.
Sansec ha individuato i primi attacchi il 4 settembre 2026 e ha pubblicato la propria analisi il giorno successivo. La vulnerabilità consente a un attaccante non autenticato di arrivare alla Remote Code Execution (RCE), sfruttando il sistema di template di Magento attraverso una catena di attacco articolata in più fasi.
La caratteristica più importante di questo episodio è la tempistica: lo sfruttamento era già in corso prima che fosse disponibile la correzione ufficiale.
Il 7 settembre 2026 Adobe ha pubblicato l’aggiornamento di emergenza APSB26-146 e l’hotfix dedicato alla vulnerabilità, identificata come CVE-2026-75650 e valutata con il massimo punteggio CVSS 10.0.
Adobe ha inoltre confermato di essere a conoscenza dello sfruttamento attivo della vulnerabilità contro installazioni Adobe Commerce e Magento.
Il giorno successivo, l’8 settembre, è stato pubblicato anche l’aggiornamento di sicurezza programmato APSB26-138. Un dettaglio importante è che questo aggiornamento non sostituiva l’hotfix dedicato a StyleSmuggler: la correzione per CVE-2026-75650 doveva essere applicata separatamente.
Anche questo episodio dimostra l’importanza di seguire costantemente i security advisory: limitarsi a verificare periodicamente la disponibilità di una nuova versione Magento può non essere sufficiente per conoscere tutti gli interventi urgenti richiesti.
Perché installare una patch può non essere sufficiente
Uno dei concetti più importanti nella gestione della sicurezza è la distinzione tra correggere una vulnerabilità ed eliminare una compromissione.
Una security patch corregge il codice vulnerabile e impedisce che quella specifica falla continui a essere sfruttata. Se però un attaccante ha già avuto accesso al sistema prima dell’applicazione della patch, potrebbe avere installato una backdoor, creato meccanismi di persistenza, modificato file oppure acquisito credenziali.
In questo scenario, applicare la patch chiude la vulnerabilità ma non rimuove automaticamente le conseguenze di un attacco già avvenuto.
Il caso StyleSmuggler è particolarmente significativo. In seguito alla pubblicazione dell’hotfix, Adobe ha raccomandato non soltanto di applicare la correzione, ma anche di procedere alla rotazione delle encryption key e delle credenziali potenzialmente esposte.
Tra queste possono rientrare password amministrative, token delle integrazioni, credenziali API dei gateway di pagamento, credenziali del database, chiavi SSH e deploy e credenziali utilizzate da servizi ed estensioni di terze parti.
Adobe ha inoltre precisato che la sola rotazione della encryption key non rende automaticamente inutilizzabili eventuali credenziali che un attaccante abbia già acquisito.
È quindi necessario distinguere sempre due attività:
- remediation, cioè la correzione della vulnerabilità;
- incident response, cioè la verifica e la gestione di un’eventuale compromissione già avvenuta.
Monitoraggio continuo e malware detection
Il monitoraggio consente di aggiungere un ulteriore livello di protezione alla normale attività di aggiornamento.
Su un eCommerce Magento è importante poter individuare tempestivamente modifiche anomale ai file, presenza di codice sospetto, nuovi processi, comportamenti inattesi, accessi insoliti o altri indicatori di compromissione.
Gli strumenti di malware detection specifici per l’eCommerce possono aiutare a individuare web shell, backdoor, skimmer e altre modifiche malevole che potrebbero non essere immediatamente visibili durante il normale utilizzo dello store.
Il monitoraggio deve essere accompagnato dall’analisi dei log applicativi e di sistema e dalla verifica delle attività anomale. In caso di incidente, la disponibilità di log adeguati può essere determinante per ricostruire ciò che è avvenuto e individuare il possibile punto di ingresso.
Un’altra misura di protezione può essere rappresentata da un Web Application Firewall (WAF), che può contribuire a bloccare determinate richieste malevole e offrire una protezione aggiuntiva durante la finestra che intercorre tra la scoperta di una vulnerabilità e l’applicazione della relativa correzione.
Il WAF non sostituisce però l’aggiornamento dell’applicazione: deve essere considerato un ulteriore livello all’interno di una strategia di sicurezza più ampia.
La sicurezza riguarda anche le estensioni Magento
Un progetto Magento reale è composto raramente dal solo core della piattaforma. Gateway di pagamento, sistemi di spedizione, strumenti SEO, marketplace, feed prodotto e numerose altre funzionalità vengono normalmente integrate attraverso moduli di terze parti.
Di conseguenza, la sicurezza dello store dipende anche dalla sicurezza e dallo stato di aggiornamento delle estensioni installate.
Nel luglio 2026, ad esempio, sono state rese note vulnerabilità che interessavano diverse estensioni Magento di terze parti, alcune delle quali classificate come critiche. È un esempio concreto di come il monitoraggio delle vulnerabilità debba comprendere non soltanto i security bulletin Adobe, ma anche gli aggiornamenti pubblicati dai vendor dei moduli utilizzati.
Per questo motivo è utile mantenere un inventario aggiornato delle estensioni presenti nello store e verificare periodicamente:
- la versione installata;
- la disponibilità di aggiornamenti di sicurezza;
- la compatibilità con la versione Magento utilizzata;
- la reale necessità del modulo;
- lo stato di manutenzione da parte del vendor.
Ridurre estensioni obsolete o non più necessarie significa anche ridurre la superficie d’attacco e semplificare la manutenzione futura della piattaforma.
Backup e incident response
Una strategia di sicurezza deve prevedere anche cosa fare quando qualcosa va storto.
I backup rappresentano una componente essenziale, ma devono essere recenti, protetti e soprattutto verificati. Disporre di un backup che non può essere ripristinato correttamente offre infatti una sicurezza soltanto apparente.
È inoltre importante conservare copie che permettano, quando necessario, di confrontare lo stato attuale dell’installazione con una versione precedente e affidabile.
In presenza di una possibile compromissione, l’intervento dovrebbe essere gestito in maniera strutturata: identificare l’origine dell’incidente, contenere l’attacco, analizzare l’installazione, eliminare eventuali meccanismi di persistenza, applicare le correzioni necessarie, ruotare le credenziali interessate e verificare l’integrità del sistema prima del ritorno alla normale operatività.
Ripristinare semplicemente un backup senza individuare e correggere la causa dell’incidente può infatti esporre nuovamente lo store allo stesso problema.
Manutenzione e assistenza Magento
Gli eventi del 2026 mostrano come la sicurezza di Magento richieda una gestione continuativa. Non è sufficiente effettuare un importante aggiornamento della piattaforma e considerare conclusa l’attività fino alla release successiva.
Un servizio di assistenza e manutenzione Magento dovrebbe comprendere il controllo periodico dello stato della piattaforma e delle estensioni, la valutazione dei security advisory, l’applicazione tempestiva delle patch necessarie e il monitoraggio dell’installazione.
La rapidità è particolarmente importante quando viene pubblicata una vulnerabilità critica. È necessario comprendere se la propria versione è interessata, verificare la presenza della correzione, valutarne la compatibilità con il progetto, effettuare i test necessari e portarla in produzione nel minor tempo possibile.
Per i progetti Magento che seguiamo, in Advanced Logic consideriamo sicurezza, aggiornamenti e monitoraggio parti dello stesso processo di manutenzione della piattaforma. L’obiettivo non è soltanto intervenire quando si manifesta un problema, ma ridurre il rischio che un incidente possa verificarsi e diminuire i tempi di reazione quando emerge una nuova vulnerabilità.
Questo approccio comprende il mantenimento della piattaforma e delle estensioni, il monitoraggio della sicurezza e l’utilizzo di strumenti specializzati per l’individuazione di malware e anomalie, insieme alla gestione dell’infrastruttura e dei sistemi di backup.
Conclusioni
PolyShell e StyleSmuggler hanno mostrato nel 2026 due scenari differenti ma accomunati dallo stesso principio: la sicurezza di un eCommerce Magento richiede attenzione continua.
Nel primo caso, per un periodo la vulnerabilità era nota mentre la correzione non era ancora disponibile per tutte le normali versioni production interessate. Nel secondo, gli attacchi sono stati osservati prima della pubblicazione dell’hotfix ufficiale e Adobe ha successivamente raccomandato ulteriori attività, tra cui la rotazione delle credenziali potenzialmente compromesse.
Le nuove isolated security patches introdotte da Adobe consentono oggi di intervenire più rapidamente su determinate vulnerabilità, ma richiedono comunque che la piattaforma venga mantenuta su un livello di aggiornamento adeguato.
Per questo una strategia efficace deve combinare aggiornamenti, security patch, controllo delle estensioni, malware detection, monitoraggio, backup e procedure di incident response.
La sicurezza non è quindi un intervento da eseguire una volta, ma un processo che accompagna l’intero ciclo di vita di un progetto Magento.
Contattaci per una verifica della sicurezza del tuo eCommerce o per informazioni sui nostri servizi di assistenza e manutenzione Magento.