Il 7 settembre 2026 Adobe ha pubblicato una patch d’emergenza fuori calendario per una falla che permette di prendere il controllo completo di un negozio online senza bisogno di credenziali. La vulnerabilità, catalogata come CVE-2026-75650, colpisce Adobe Commerce e Magento Open Source e ha ricevuto il punteggio massimo di gravità: CVSS 10.0 su 10. Il giorno dopo, l’8 settembre, la statunitense CISA l’ha aggiunta al proprio catalogo delle vulnerabilità sfruttate attivamente (KEV) e ha imposto una scadenza di appena tre giorni per la messa in sicurezza, una delle finestre più corte mai fissate quest’anno per una falla di questa categoria.
Dietro la scoperta c’è Sansec, la società di ricerca specializzata in malware per l’e-commerce che da anni monitora gli attacchi contro Magento. Il suo report, pubblicato il 5 settembre 2026 con il nome in codice “StyleSmuggler”, descrive un bug nel motore dei template che consente l’esecuzione di codice arbitrario senza autenticazione. Gli attacchi reali, secondo Sansec, erano già in corso dal 4 settembre, un giorno prima della disclosure pubblica: si tratta quindi di uno zero-day sfruttato in the wild, non di una falla scoperta a tavolino.
Cosa è successo: cronologia di un attacco in quattro giorni
La tempistica di questo incidente è insolitamente compressa rispetto agli standard del settore. Normalmente passano settimane tra la scoperta di una falla critica e l’aggiunta al catalogo KEV di CISA, con finestre di correzione di 15-21 giorni. Qui la sequenza è stata quasi immediata, segno che sia Adobe sia le autorità statunitensi hanno trattato il caso come un’emergenza attiva e non come una vulnerabilità teorica.
- 4 settembre 2026: primi tentativi di sfruttamento osservati contro negozi Adobe Commerce e Magento esposti in rete.
- 5 settembre 2026: Sansec pubblica la ricerca “StyleSmuggler” e avvisa i clienti dell’attività sospetta.
- 7 settembre 2026: Adobe rilascia l’hotfix d’emergenza tramite il bollettino APSB26-146.
- 8 settembre 2026: CISA inserisce CVE-2026-75650 nel catalogo Known Exploited Vulnerabilities.
- 11 settembre 2026: scade il termine fissato da CISA per le agenzie federali statunitensi, appena tre giorni dopo l’inserimento in KEV.
La finestra di tre giorni tra l’aggiunta al catalogo e la scadenza non è casuale. Nel testo della direttiva, CISA fa riferimento alla BOD 26-04, la direttiva operativa vincolante che impone alle agenzie federali di dare priorità agli aggiornamenti in base al rischio reale. Nella scheda della vulnerabilità compare anche il campo “forensicTriage” impostato su “Yes”: un dettaglio che CISA riserva ai casi in cui ritiene probabile una compromissione già avvenuta, non solo possibile. In pratica, l’agenzia chiede alle organizzazioni colpite non solo di applicare la patch, ma anche di verificare se qualcuno sia già entrato prima del rilascio del fix.
Come funziona CVE-2026-75650: la falla nel motore dei template
Tecnicamente la vulnerabilità è classificata come CWE-1336, “Improper Neutralization of Special Elements Used in a Template Engine”. In parole semplici, il motore che genera dinamicamente le pagine del negozio non filtra correttamente alcuni input, permettendo a un aggressore di inserire codice che viene poi interpretato ed eseguito dal server. Il risultato pratico è l’esecuzione di comandi arbitrari sul sistema, con gli stessi privilegi del processo che gestisce lo store.
Il vettore osservato da Sansec sfrutta richieste non autenticate contro l’endpoint /graphql, presente di default su qualunque installazione moderna di Magento e usato dai temi headless e dalle app mobile collegate al negozio. Chi espone questo endpoint pubblicamente, cosa ormai standard per la maggior parte dei siti che usano il frontend PWA Studio o integrazioni di terze parti, è automaticamente raggiungibile dall’attacco. Non serve un account amministratore, non serve un cookie di sessione valido: basta una richiesta HTTP verso un endpoint che quasi ogni negozio online ha aperto per funzionare normalmente.
Chi vuole verificare se il proprio sistema abbia ricevuto tentativi sospetti può partire dai log del web server, cercando pattern anomali nelle richieste verso l’endpoint GraphQL nei giorni precedenti alla patch.
# Ricerca di richieste sospette verso /graphql nei log Apache/Nginx
# tra il 4 e il 7 settembre 2026 (finestra di attacco pre-patch)
grep "POST /graphql" access.log | awk '$4 >= "[04/Sep/2026" && $4 <= "[07/Sep/2026"' | wc -l
# Verifica della versione installata via Composer
composer show magento/product-community-edition | grep versionsChi è a rischio: le versioni colpite
Il bollettino Adobe elenca tre linee di prodotto interessate. Adobe Commerce dalla versione 2.4.4 fino alla 2.4.9, Adobe Commerce B2B dalla 1.3.3 alla 1.5.3, e Magento Open Source dalla 2.4.6 alla 2.4.9. In pratica, quasi ogni installazione attiva negli ultimi quattro anni rientra nel perimetro vulnerabile, comprese le release di agosto 2026 di ciascun ramo. Chi gestisce ambienti Adobe Commerce Cloud ha ricevuto la patch in modo automatico dal team Adobe, mentre chi opera installazioni self-hosted, la maggioranza dei negozi Magento Open Source, deve applicare l'hotfix manualmente o tramite Composer.
Va detto che una parte consistente del parco installato non ha team dedicati alla sicurezza applicativa. È lo stesso scenario già visto con altre falle critiche del 2026, dal caso di SAP Commerce Cloud, che aveva lasciato migliaia di istanze esposte, fino ai problemi di autenticazione emersi su JFrog Artifactory. Il denominatore comune è sempre lo stesso: software enterprise diffuso, patch disponibile in tempi rapidi, ma adozione lenta sul campo.
La scheda tecnica della vulnerabilità
| Campo | Dettaglio |
|---|---|
| Identificativo CVE | CVE-2026-75650 |
| Bollettino Adobe | APSB26-146 |
| Punteggio CVSS | 10.0 (Critico) |
| Categoria (CWE) | CWE-1336, iniezione nel motore dei template |
| Impatto | Esecuzione di codice remoto non autenticata |
| Vettore osservato | Endpoint /graphql esposto pubblicamente |
| Prodotti colpiti | Adobe Commerce 2.4.4-2.4.9, Adobe Commerce B2B 1.3.3-1.5.3, Magento Open Source 2.4.6-2.4.9 |
| Sfruttamento attivo dal | 4 settembre 2026 |
| Disclosure Sansec | 5 settembre 2026 |
| Patch Adobe | 7 settembre 2026 |
| Inserimento in CISA KEV | 8 settembre 2026 |
| Scadenza rimedio CISA | 11 settembre 2026 (3 giorni) |
Perché CISA ha scelto una scadenza così corta
Il catalogo CISA KEV conta oggi 1.709 voci complessive, accumulate dal 2021 a questa parte. La stragrande maggioranza riceve un termine di correzione compreso tra due e tre settimane. Una scadenza di tre giorni, come quella assegnata a CVE-2026-75650, è riservata ai casi in cui l'agenzia ha prove di sfruttamento già in corso su larga scala o di un rischio concreto per infrastrutture critiche collegate. Il fatto che la scheda della vulnerabilità richieda esplicitamente un'attività di "forensic triage" rafforza questa lettura: non basta patchare, bisogna anche controllare se qualcuno sia già entrato.
Per chi segue le vulnerabilità critiche pubblicate quest'anno, il confronto con il caso CISA KEV rispetto al database europeo ENISA EUVD resta utile: mentre il catalogo americano si concentra su un numero limitato di falle davvero sfruttate, l'equivalente europeo cataloga un volume di vulnerabilità molto più ampio, con priorità meno immediate. Per le aziende italiane, questo significa che l'allarme reale spesso arriva prima dagli Stati Uniti che dai canali europei.
L'impatto sul mercato: quanti negozi usano Magento
Per capire la portata del problema serve guardare ai numeri di adozione della piattaforma. Secondo i dati pubblici di BuiltWith, Magento 2, la generazione toccata dalla falla, conta oggi 71.276 siti attivi a livello globale, su un totale storico di 226.420 installazioni rilevate dal lancio della piattaforma a oggi. A livello europeo, BuiltWith registra 46.136 negozi Magento attivi complessivi, di cui 27.301 concentrati nella sola Europa occidentale.
Il quadro italiano emerge dai dati di Storeleads, che censisce 2.684 negozi Magento attivi nel paese, in calo del 24% su base annua nel secondo trimestre 2026, segno di una migrazione già in corso verso altre piattaforme di e-commerce. Per confronto, la Germania conta 6.994 negozi attivi e gli Stati Uniti 14.130. Anche con un mercato più piccolo rispetto ai due giganti citati, le migliaia di negozi italiani ancora su Magento restano un bersaglio concreto, soprattutto quelli che non hanno aggiornato nei giorni successivi al rilascio della patch.
Diffusione di Magento per area geografica
| Area / Paese | Negozi Magento attivi | Fonte |
|---|---|---|
| Globale (Magento 2) | 71.276 | BuiltWith |
| Storico globale (Magento 2) | 226.420 | BuiltWith |
| Europa | 46.136 | BuiltWith |
| Europa occidentale | 27.301 | BuiltWith |
| Germania | 6.994 | Storeleads |
| Stati Uniti | 14.130 | Storeleads |
| Italia | 2.684 (-24% annuo) | Storeleads |
Confronto con le altre falle critiche RCE del 2026
CVE-2026-75650 non è un caso isolato. Il 2026 ha già visto una serie di vulnerabilità con punteggio massimo o quasi massimo colpire software enterprise molto diffuso. Il confronto con questi casi aiuta a capire dove si colloca la falla Adobe nella scala di gravità e urgenza vista quest'anno.
| Vulnerabilità | Prodotto | CVSS | Tipo |
|---|---|---|---|
| CVE-2026-75650 | Adobe Commerce / Magento | 10.0 | RCE non autenticata via template |
| CVE-2026-58231 | SAP Commerce Cloud | 10.0 | RCE critica |
| CVE-2026-56162 | Azure SQL Database | 10.0 | Escalation critica |
| CVE-2026-63077 | JetBrains TeamCity | 9.8 | RCE supply chain |
| CVE-2026-82329 | JFrog Artifactory | 9.8 | Bypass autenticazione |
| CVE-2026-72982 | Netlogon (Patch Tuesday) | 9.8 | Escalation di privilegio |
Quello che accomuna questi casi è la combinazione tra software largamente adottato e tempo di reazione ridotto al minimo. Rispetto al Patch Tuesday di settembre 2026, che ha corretto centinaia di vulnerabilità in un colpo solo, il caso Adobe riguarda una falla singola ma con una velocità di sfruttamento decisamente superiore: l'attacco era già attivo prima ancora della disclosure pubblica, mentre per Netlogon lo sfruttamento su larga scala è arrivato solo dopo la pubblicazione dei dettagli tecnici.
Il contesto storico: Magento come bersaglio ricorrente
Magento non è nuova a episodi di questo tipo. La piattaforma, nata come progetto open source e poi acquisita da Adobe, gestisce da anni una fetta rilevante del commercio elettronico globale ed è per questo un bersaglio costante delle campagne di skimming digitale, quelle in cui un aggressore inserisce codice malevolo nelle pagine di pagamento per rubare i dati delle carte di credito al momento del checkout. La storia recente della piattaforma è fatta di cicli ricorrenti: scoperta di una falla critica, patch d'emergenza, ondata di scansioni automatizzate contro i siti non aggiornati, comparsa dei primi casi di furto dati nelle settimane successive.
Quello che cambia in questo episodio è la velocità. Il tempo tra i primi attacchi osservati e la disponibilità di una patch è stato di appena tre giorni, un intervallo che lascia poco margine ai team di sicurezza per reagire prima che gli exploit vengano automatizzati e distribuiti su scala più ampia dai gruppi criminali meno sofisticati.
Cosa devono fare ora i team IT
La prima azione, ovvia ma spesso disattesa, è applicare l'hotfix pubblicato da Adobe nel bollettino APSB26-146, verificando la versione esatta installata prima di procedere. Chi opera su Adobe Commerce Cloud dovrebbe già aver ricevuto l'aggiornamento in automatico, ma è comunque opportuno confermarlo con il proprio referente Adobe.
La seconda azione, quella che CISA sottolinea con il riferimento al "forensic triage", riguarda la verifica di una possibile compromissione avvenuta prima della patch. Questo significa controllare la presenza di file inattesi nelle directory del tema, account amministratore creati di recente e senza autorizzazione, e job pianificati (cron) sospetti. Chi gestisce l'endpoint /graphql esposto pubblicamente dovrebbe inoltre valutare di limitarne l'accesso tramite web application firewall, almeno fino a quando non sarà certo che l'ambiente sia pulito.
Per le organizzazioni italiane soggette alla direttiva NIS2, questo tipo di incidente rientra nell'obbligo di notifica in caso di compromissione confermata, un tema di cui trovi il quadro generale nella nostra sezione sicurezza.
Impatto sul mercato e sulla fiducia degli operatori e-commerce
L'effetto immediato di un episodio come questo si misura su due piani. Sul piano operativo, i team tecnici devono dedicare risorse non pianificate a patch d'emergenza e verifiche forensi, con un costo diretto in ore di lavoro che per una media impresa italiana può facilmente superare le poche migliaia di euro tra consulenza esterna e fermo eventuale del sito durante gli aggiornamenti. Sul piano reputazionale, un negozio online che subisce un furto di dati delle carte di pagamento rischia sanzioni sotto il regime PCI DSS oltre a un danno d'immagine difficile da quantificare ma reale, soprattutto per i merchant più piccoli che non hanno un piano di comunicazione crisi già pronto.
Il calo del 24% nell'uso di Magento in Italia osservato da Storeleads racconta probabilmente anche questo: una migrazione progressiva verso piattaforme percepite come più semplici da mantenere in sicurezza, che penalizza chi non aveva già pianificato un passaggio ad altre soluzioni prima che scoppiasse l'ennesimo caso critico.
Previsioni per i prossimi mesi
- È probabile che nelle prossime settimane emergano i primi casi documentati di skimming Magecart legati a negozi compromessi prima della patch del 7 settembre, secondo lo schema già visto in passato con altre falle Magento.
- Ci si può aspettare un aumento delle scansioni automatizzate contro l'endpoint /graphql anche su altre piattaforme di e-commerce basate su GraphQL, non solo Magento, mano a mano che i gruppi criminali affinano gli strumenti derivati da questo exploit.
- È ragionevole prevedere che CISA continui a usare scadenze di pochi giorni, invece delle tradizionali due o tre settimane, per le vulnerabilità con prove di sfruttamento pre-disclosure, un cambio di approccio già visibile in questo caso.
- Il calo di adozione di Magento in Italia osservato nel 2026 dovrebbe accelerare ulteriormente, con più merchant che valutano la migrazione durante i cicli di rinnovo contrattuale successivi a incidenti come questo.
- È verosimile che la Commissione Europea e le autorità NIS2 nazionali usino questo episodio come caso di studio per chiarire gli obblighi di notifica applicabili ai gestori di infrastrutture di e-commerce di medie dimensioni, area finora poco normata nel dettaglio.
Perché una vulnerabilità nel motore dei template è così pericolosa
Le falle di tipo SSTI (Server-Side Template Injection), a cui CWE-1336 appartiene concettualmente, sono tra le classi di vulnerabilità più pericolose in assoluto perché saltano un passaggio intermedio che normalmente protegge le applicazioni web. In un'iniezione SQL classica l'aggressore deve prima trovare un modo per manipolare una query verso il database, mentre in un'iniezione nel motore dei template il codice inserito viene interpretato direttamente dal linguaggio di programmazione sottostante, spesso PHP nel caso di Magento. Questo significa che il salto da "input malevolo" a "comando eseguito sul server" è molto più corto, e nella maggior parte dei casi non richiede tecniche di bypass elaborate.
Nel caso di CVE-2026-75650 l'assenza di autenticazione toglie anche l'ultimo ostacolo che normalmente rallenta un attacco del genere. Molte falle critiche del 2026, incluse quelle emerse su JFrog Artifactory, richiedevano comunque un passaggio preliminare per aggirare i controlli di accesso. Qui basta la sola raggiungibilità di rete verso l'endpoint GraphQL, un requisito che la stragrande maggioranza dei negozi Magento soddisfa per costruzione, dato che l'endpoint serve a far funzionare il frontend del sito stesso.
Il ruolo di Sansec e la ricerca indipendente sulla sicurezza e-commerce
Vale la pena sottolineare il ruolo di Sansec in questa vicenda. L'azienda, specializzata esclusivamente nella sicurezza delle piattaforme di commercio elettronico, ha una lunga storia di scoperte di questo tipo e pubblica report tecnici dettagliati che spesso anticipano di giorni le comunicazioni ufficiali dei vendor. Il nome in codice "StyleSmuggler", scelto per descrivere la tecnica di iniezione nel motore dei template, è già diventato il riferimento comune usato dalla community di sicurezza per parlare di questo incidente, anche nei bollettini ufficiali che rimandano al report originale.
Questo tipo di collaborazione tra ricercatori indipendenti e vendor, quando funziona bene, comprime drasticamente i tempi di reazione. Qui sono bastati due giorni tra la disclosure di Sansec e la patch ufficiale Adobe, un ritmo che molte falle enterprise non riescono a eguagliare nemmeno dopo settimane. Per approfondire l'analisi tecnica completa dell'exploit, la documentazione ufficiale resta consultabile sulla scheda NVD di CVE-2026-75650 e sul resoconto di BleepingComputer, mentre l'elenco aggiornato delle vulnerabilità sfruttate resta consultabile nel catalogo KEV pubblicato da CISA.
Domande frequenti
Cos'è la CVE-2026-75650?
È una vulnerabilità critica, con punteggio CVSS 10.0, che colpisce Adobe Commerce e Magento Open Source. Permette a un aggressore di eseguire codice arbitrario sul server senza bisogno di credenziali, sfruttando un difetto nel motore dei template della piattaforma.
Quali versioni di Adobe Commerce e Magento sono vulnerabili?
Adobe Commerce dalla 2.4.4 alla 2.4.9, Adobe Commerce B2B dalla 1.3.3 alla 1.5.3 e Magento Open Source dalla 2.4.6 alla 2.4.9, comprese le release di agosto 2026 di ciascun ramo.
La falla è già stata sfruttata attivamente?
Sì. Secondo Sansec gli attacchi erano in corso dal 4 settembre 2026, un giorno prima della disclosure pubblica del 5 settembre. CISA ha confermato lo sfruttamento attivo inserendo la falla nel catalogo KEV l'8 settembre.
Come posso sapere se il mio sito è stato compromesso?
Controlla i log del web server per richieste POST sospette verso l'endpoint /graphql tra il 4 e il 7 settembre 2026, verifica la presenza di account amministratore creati senza autorizzazione e controlla i job cron pianificati non riconosciuti.
Qual è la scadenza fissata da CISA per applicare la patch?
Per le agenzie federali statunitensi la scadenza era l'11 settembre 2026, tre giorni dopo l'inserimento nel catalogo KEV. Per le aziende private non esiste un obbligo legale equivalente, ma la raccomandazione è di applicare la patch il prima possibile visto lo sfruttamento già in corso.
La vulnerabilità riguarda anche l'Italia?
Sì. Storeleads censisce 2.684 negozi Magento ancora attivi in Italia. Chiunque gestisca una di queste installazioni senza aver applicato l'hotfix del 7 settembre resta esposto.
Cosa succede se non applico la patch in tempo?
Il rischio concreto è la compromissione completa del server, con possibile installazione di skimmer per il furto dei dati delle carte di pagamento, creazione di backdoor persistenti o uso del sito come punto d'appoggio per altri attacchi.
Cosa cambia con la direttiva NIS2 per chi gestisce un negozio Magento?
Le organizzazioni italiane che rientrano nel perimetro NIS2 e subiscono una compromissione confermata legata a questa falla devono notificarla alle autorità competenti entro le tempistiche previste dalla direttiva, generalmente entro 24 ore dalla scoperta dell'incidente significativo.
