Il 7 settembre Adobe ha pubblicato APSB26-146, per una vulnerabilità che ha già un soprannome informale, “StyleSmuggler”, e un punteggio CVSS di 10.0: esecuzione di codice arbitrario, non autenticata, su Adobe Commerce e Magento Open Source, già sfruttata attivamente prima ancora che la patch uscisse. Il 24 settembre CISA l’ha aggiunta al proprio catalogo delle vulnerabilità sfruttate, insieme a un secondo CVE su Adobe Commerce, con scadenza per le agenzie federali fissata al 27.
Di bollettini critici su questa piattaforma ne ho già scritto, a luglio, parlando di disciplina di patching. Questo è diverso, e non per il punteggio: è diverso per quello che chiede di fare dopo aver applicato la patch.
Non è un hotfix, è un cambio di chiavi
La correzione tecnica è un hotfix mirato (Adobe lo ha chiamato VULN-39341), compatibile con le versioni tra la 2.4.4 e la 2.4.7, applicabile senza attendere una minor release completa. Fin qui, niente di diverso dal solito. La parte che cambia la scala del lavoro è la raccomandazione che segue l’hotfix: ruotare la chiave di cifratura del sito, e con essa tutte le credenziali che quella chiave protegge.
La chiave di cifratura di Adobe Commerce non è un dettaglio isolato. Cifra i token di integrazione, le credenziali dei gateway di pagamento, i token di automazione con privilegi di sistema. Se un attaccante ha avuto accesso al database prima della patch (e qui il punto è che questa vulnerabilità permetteva esecuzione di codice, quindi l’ipotesi non è remota), ruotare la chiave non basta: vanno ruotate anche le credenziali che quella chiave cifrava, una per una. Gateway di pagamento, token API, password amministrative, credenziali di database, chiavi SSH.
Perché questo tipo di lavoro viene sistematicamente sottostimato
Non ho ancora gestito una remediation completa di questo specifico bollettino su un caso reale: scrivo questo pezzo prima di averlo fatto, non dopo, e lo dico apertamente perché è la differenza che mi interessa tenere onesta. Quello che segue è un ragionamento su come funziona di solito questo tipo di intervento, non il resoconto di un intervento fatto.
Nella mia esperienza di questi anni su ambienti Adobe Commerce, la reazione a un bollettino critico segue quasi sempre lo stesso schema: si legge il CVSS, si stima un giorno o due per applicare la patch, si comunica al cliente una finestra di intervento breve. È un rischio quasi triviale da prioritizzare, il CVSS 10.0 fa il lavoro da solo. Il problema è che quella stima copre solo l’hotfix, e la rotazione delle credenziali è un progetto diverso travestito da riga in più nella checklist.
Ruotare una credenziale di gateway di pagamento non è cambiare un valore in un file di configurazione. Vuol dire coordinarsi con il fornitore del gateway, verificare che la nuova credenziale sia propagata su tutti gli ambienti (produzione, staging, eventuali integrazioni di terze parti che leggono lo stesso valore), e testare che nessun flusso di checkout si rompa nel frattempo. Lo stesso vale per i token di automazione: se un MCP, come quello di cui ho scritto qui, usa un integration token cifrato con la vecchia chiave, quel token smette di funzionare silenziosamente finché qualcuno non se ne accorge, di solito quando un job schedulato fallisce nel weekend.
Il contro-argomento: “il CVSS basta a far muovere tutti”
Si potrebbe dire che sto complicando qualcosa che in pratica funziona già: un CVSS 10.0 con exploit attivo fa scattare la priorità massima ovunque, quindi perché insistere sulla rotazione delle chiavi separatamente? Perché la priorità massima si applica all’hotfix, non al lavoro che segue. Ho visto, in generale e non su questo bollettino specifico, team applicare la patch nella finestra promessa e poi chiudere il ticket, lasciando la rotazione delle credenziali in una nota “da fare” che resta aperta per settimane perché non ha la stessa urgenza percepita di un CVE con nome e punteggio.
È lì che si crea l’esposizione residua: la vulnerabilità è chiusa, ma le credenziali potenzialmente compromesse restano quelle di prima.
Cosa farei, e come lo verificherò
Se dovessi gestire questa remediation su un ambiente reale, la tratterei come due progetti separati con due scadenze separate: l’hotfix entro 24-48 ore, la rotazione completa delle credenziali entro una settimana, con un elenco esplicito di ogni sistema che dipende dalla chiave del sito, non solo dei tre o quattro più ovvi. È un’ipotesi di metodo, non un resoconto. Se mi capiterà di applicarla su un caso vero prima che questo pezzo invecchi, tornerò a scriverne con i numeri veri.
Mini-FAQ
Cos’è APSB26-146?
Il bollettino di sicurezza pubblicato da Adobe il 7 settembre 2026 per CVE-2026-75650, una vulnerabilità di esecuzione di codice remoto non autenticata su Adobe Commerce e Magento Open Source, con CVSS 10.0 e sfruttamento attivo già rilevato.
Basta applicare l’hotfix per essere al sicuro?
No. Adobe raccomanda anche la rotazione della chiave di cifratura del sito e di tutte le credenziali che quella chiave protegge: gateway di pagamento, token API, credenziali amministrative e di database, chiavi SSH.
Perché è finita nel catalogo CISA KEV?
Il 24 settembre 2026 CISA ha aggiunto CVE-2026-75650, insieme a un secondo CVE su Adobe Commerce (CVE-2026-71362), al catalogo delle vulnerabilità note sfruttate, con scadenza di intervento per le agenzie federali statunitensi al 27 settembre.
Chi sono. Sono Fabio Canovi, consulente Adobe italiano specializzato nell’AI agentica, presso il gruppo Lutech, certificato Adobe Commerce, Adobe Experience Manager, Adobe Analytics e Adobe Target. Costruisco integrazioni AI agentiche basate su MCP per il mondo Adobe, e scrivo di quello che imparo mentre le realizzo.