In sintesi
CVE-2026-75650, che la società olandese di sicurezza e-commerce Sansec chiama StyleSmuggler, è un'esecuzione di codice remoto senza autenticazione con punteggio CVSS 10.0 in Adobe Commerce e Magento Open Source — ed era già sfruttata prima che Adobe rilasciasse una correzione. Gli attaccanti abusano dell'elaborazione dei template di Magento per iniettare ed eseguire PHP arbitrario sul server, senza account e senza clic. Se il vostro negozio gira su una versione vulnerabile, l'ipotesi prudente non è «aggiorniamo quando capita», ma «potremmo essere già stati violati». Per qualsiasi azienda che considera il proprio negozio Magento il motore del fatturato, patch e verifica di compromissione vanno fatte in giornata.
Che cos'è StyleSmuggler
Sansec, società di sicurezza specializzata in Magento, ha reso nota la CVE-2026-75650 dopo averla individuata in attacchi reali. Si tratta di una vulnerabilità di code injection nel motore di template di Magento: l'attaccante invia un input appositamente costruito che la piattaforma, durante l'elaborazione dei template, valuta come PHP, ottenendo così l'esecuzione di codice arbitrario sul server web. Il percorso di attacco osservato da Sansec passa per la funzione «Payment Transaction Failed Reminder», una normale funzione e-mail del negozio che risulta raggiungibile senza autenticazione.
È questa combinazione a renderla lo scenario peggiore per un negozio pubblico. Non c'è un login da aggirare, né una sessione admin da rubare, né un passaggio di phishing per convincere un utente a cliccare. Un negozio semplicemente online e su una versione vulnerabile è attaccabile da chiunque possa raggiungerlo in rete. Per la maggior parte dei negozi Magento — che esistono proprio per essere trovati e visitati — la superficie di attacco è quindi l'intera Internet.
Adobe ha assegnato al problema la priorità più alta e l'8 settembre 2026 ha rilasciato un hotfix fuori ciclo, tracciato internamente come VULN-39341. Lo stesso giorno l'agenzia statunitense per la cybersicurezza e la sicurezza delle infrastrutture (CISA) ha inserito la CVE-2026-75650 nel catalogo Known Exploited Vulnerabilities (KEV), fissando alle agenzie federali la scadenza dell'11 settembre — un termine così stretto che la CISA riserva alle falle sotto attacco attivo.
Perché il punteggio è un 10 pieno
Un punteggio base CVSS di 10.0 viene assegnato raramente: la vulnerabilità deve risultare al peggio su ogni asse misurato dal modello. StyleSmuggler li soddisfa tutti: l'attacco avviene via rete, la complessità è bassa, non servono privilegi né interazione dell'utente — e uno sfruttamento riuscito può compromettere completamente riservatezza, integrità e disponibilità del sistema colpito.
Fuori dal gergo del punteggio, significa che un attaccante remoto e anonimo può prendere il controllo completo del server con una sola richiesta, e che tutto ciò che il negozio tocca è esposto: anagrafiche clienti, storico ordini, metadati di pagamento salvati, account admin e le credenziali del database dell'applicazione. Su un server Magento l'esecuzione di codice remoto equivale di fatto a partita persa, perché il processo web può leggere i segreti dell'applicazione e raggiungere direttamente il database.
Adobe indica come release colpite Adobe Commerce dalla 2.4.4 alla 2.4.9 (build 2026-aug e precedenti), Adobe Commerce B2B nell'intervallo 1.3.3–1.5.3 e Magento Open Source dalla 2.4.6 alla 2.4.9. Questo intervallo copre la stragrande maggioranza delle installazioni Magento in produzione, comprese le installazioni Open Source self-hosted gestite da piccoli merchant e agenzie senza un team di sicurezza dedicato.
Come è stata sfruttata prima della patch
Il dettaglio che dovrebbe ricalibrare il vostro modello di rischio è la cronologia. Sansec ha confermato lo sfruttamento a partire dal 4 settembre 2026 — quattro giorni prima che Adobe avesse una correzione da offrire. È stato un vero zero-day: in quella finestra non c'era nessuna patch da installare né alcun bollettino del vendor, solo attaccanti che entravano in silenzio. Qualsiasi negozio esposto su Internet e non aggiornato in quei giorni va trattato come potenzialmente compromesso, non solo «a rischio».
Ciò che gli attaccanti hanno fatto una volta dentro sopravvive alla patch. Sansec ha segnalato due famiglie di payload: una backdoor Linux scritta in Rust che si collega a server di comando e controllo esterni per un accesso remoto persistente e, in intrusioni separate, una web shell PHP che permette di eseguire comandi PHP arbitrari attraverso il negozio stesso. Entrambe sono pensate per sopravvivere a un aggiornamento successivo: una backdoor installata a inizio settembre non si rimuove da sola quando installate l'hotfix dell'8 settembre.
Per questo le indicazioni ufficiali vanno oltre la patch. Poiché gli attaccanti potrebbero aver già letto i segreti del negozio, si raccomanda di ruotare le chiavi di cifratura e tutte le credenziali collegate nei sistemi di origine — password admin, credenziali del database, token di integrazione, chiavi SSH e chiavi API. Se un server Magento era esposto durante la finestra, le sue chiavi vanno considerate bruciate.
Cosa significa per gli e-commerce italiani
Primo: trattatelo come un intervento di incident response, non come un ciclo di patch. L'istinto davanti a una notizia di patch è pianificare l'aggiornamento e andare avanti; StyleSmuggler rompe questo istinto perché lo sfruttamento è iniziato prima della correzione. La sequenza corretta per qualsiasi operatore e-commerce su Magento è: installare subito l'hotfix, poi presumere che il negozio possa essere stato raggiunto e cercare tracce di conseguenza. Una patch pulita su un server già compromesso dà un falso senso di sicurezza.
Cosa significa per il mercato italiano: in Italia Magento è molto diffuso tra le PMI del retail e del made in Italy che vendono online, spesso in negozi sviluppati da una web agency e ospitati presso un provider che aggiorna il sistema operativo ma non l'applicazione. È proprio questa divisione poco chiara delle responsabilità a rendere pericoloso uno zero-day del genere. L'Agenzia per la Cybersicurezza Nazionale (ACN), tramite il CSIRT Italia, raccomanda costantemente di applicare con priorità gli aggiornamenti critici dei sistemi esposti su Internet; per un negozio che gestisce account clienti e pagamenti vale senza eccezioni.
Secondo: l'orologio della conformità corre accanto a quello tecnico. Un negozio Magento tratta dati delle carte e dati personali, quindi ricade sotto PCI DSS e GDPR. Se emergono prove che gli attaccanti hanno avuto accesso a dati di clienti o di pagamento, l'obbligo di notifica può scattare dal momento in cui ne venite a conoscenza: ai sensi dell'articolo 33 del GDPR la violazione va notificata al Garante per la protezione dei dati personali entro 72 ore, se presenta un rischio per gli interessati. La valutazione dell'esposizione non è quindi una pulizia facoltativa: è ciò che vi dice se avete una violazione da notificare.
Terzo: siate onesti su chi sorveglia davvero il negozio. Molti merchant fanno girare Magento Open Source sulla propria infrastruttura, con un'agenzia che ha realizzato il sito anni fa e un hosting provider che aggiorna il sistema operativo ma non l'applicazione. Questo vuoto — nessuno chiaramente responsabile della sicurezza applicativa — è esattamente il punto in cui una RCE senza autenticazione diventa una compromissione lunga mesi. Se il vostro team non sa rispondere a «che versione usiamo, era esposta il 4 settembre e che aspetto avrebbe una web shell sul nostro server», è la prima lacuna da colmare, idealmente con ingegneri che conoscono sia i meccanismi interni di Magento sia l'infrastruttura che lo circonda.
Checklist: aggiornare e cercare tracce
- Verificate la versione. Individuate la build esatta di Adobe Commerce o Magento Open Source in ogni ambiente e segnalate tutto ciò che, nell'intervallo 2.4.4–2.4.9, era esposto su Internet.
- Installate VULN-39341 adesso. Applicate l'hotfix fuori ciclo di Adobe per la CVE-2026-75650, poi verificate che sia davvero la versione corretta a essere in esecuzione, non solo scaricata.
- Se eravate esposti, presumete la compromissione. Se il negozio era raggiungibile e non aggiornato tra il 4 e l'8 settembre, avviate un'incident response invece di dichiarare vittoria a patch installata.
- Ruotate tutto. Cambiate chiavi di cifratura, password admin, credenziali del database, token di integrazione, chiavi SSH e chiavi API nei sistemi di origine.
- Cercate la persistenza. Verificate la presenza di file PHP e web shell inattesi, cron job sconosciuti, nuovi utenti admin e connessioni in uscita verso host sconosciuti (il segno distintivo della backdoor in Rust).
- Controllate il percorso di conformità. Se dati di clienti o di pagamento potrebbero essere stati raggiunti, attivate la procedura PCI DSS e di notifica GDPR e coinvolgete il vostro DPO prima che la scadenza decida al posto vostro.
Domande frequenti
Che cos'è la vulnerabilità Magento StyleSmuggler (CVE-2026-75650)?
La CVE-2026-75650, battezzata StyleSmuggler dalla società di sicurezza Sansec, è una falla di code injection con punteggio CVSS 10.0 in Adobe Commerce e Magento Open Source che consente l'esecuzione di codice remoto senza autenticazione. Gli attaccanti abusano dell'elaborazione dei template di Magento, raggiungibile tramite la funzione Payment Transaction Failed Reminder, per iniettare ed eseguire PHP arbitrario sul server. Poiché non servono un account valido né l'interazione dell'utente, ogni negozio esposto su Internet con una versione vulnerabile va considerato un bersaglio prioritario.
Quali versioni di Adobe Commerce e Magento sono interessate?
Secondo il bollettino di Adobe, sono interessate Adobe Commerce dalla 2.4.4 alla 2.4.9 (release 2026-aug e precedenti), Adobe Commerce B2B (dalla 1.3.3 alla 1.5.3) e Magento Open Source dalla 2.4.6 alla 2.4.9. L'8 settembre 2026 Adobe ha rilasciato una correzione fuori ciclo di priorità 1 (VULN-39341), da installare immediatamente.
La CVE-2026-75650 viene sfruttata attivamente?
Sì. Sansec ha confermato lo sfruttamento attivo dal 4 settembre 2026, diversi giorni prima della correzione di Adobe. Gli attaccanti hanno installato una backdoor Linux scritta in Rust che contatta server di comando esterni e, in attacchi separati, una web shell PHP in grado di eseguire comandi PHP arbitrari. La CISA ha aggiunto la falla al catalogo Known Exploited Vulnerabilities l'8 settembre, con scadenza federale all'11 settembre 2026.
Basta installare la patch o serve altro?
La patch blocca nuove intrusioni ma non annulla una compromissione già avvenuta durante la finestra di esposizione. Poiché lo zero-day è stato sfruttato prima che esistesse la correzione, i negozi vulnerabili devono presumere una possibile compromissione: installare l'hotfix VULN-39341, poi ruotare le chiavi di cifratura e tutte le credenziali collegate, comprese password admin, credenziali del database, token di integrazione, chiavi SSH e chiavi API. Cercate file PHP, cron job e connessioni in uscita inattesi e controllate ordini e utenti admin creati da inizio settembre.
Bisogna notificare la violazione al Garante Privacy?
Potenzialmente sì. Se emergono indizi che gli attaccanti abbiano avuto accesso a dati di clienti o di pagamento e la violazione presenta un rischio per gli interessati, l'articolo 33 del GDPR impone la notifica al Garante per la protezione dei dati personali entro 72 ore dalla scoperta. Documentate comunque la valutazione e coinvolgete il DPO fin dall'inizio dell'analisi.
Fonti
Adobe — Security update available for Adobe Commerce (APSB26-52, CVE-2026-75650)
The Hacker News — Adobe Patches Magento Zero-Day Exploited to Deploy Rust Backdoor and PHP Web Shell (September 2026)
SecurityWeek — Adobe Patches Over 170 Vulnerabilities, Including Commerce Zero-Day (September 8, 2026)