Il 14 luglio Adobe ha pubblicato il bollettino APSB26-73: tredici vulnerabilità su Adobe Commerce e Magento Open Source, otto delle quali critiche. La più grave, CVE-2026-48358, ha un punteggio CVSS di 10.0: esecuzione di codice arbitrario, senza autenticazione, senza bisogno che nessuno clicchi niente, attraverso il componente webhook. Lo stesso giorno, Mage-OS ha rilasciato la versione 3.2.0, che isola la patch di Adobe e la applica al fork open source, insieme a un bug separato sul carrello ospite e a una falla minore nell’installer che poteva lasciare credenziali in un file leggibile da chiunque.
Ho letto la sequenza di annunci con l’attenzione di chi ha passato anni a schedulare finestre di manutenzione su installazioni Commerce vere, non su demo. E la prima cosa che mi è venuta in mente non è stata “quanto è grave questa CVE”, ma un dibattito che sento ricorrere ogni volta che succede qualcosa del genere: se sei su Magento Open Source o su Mage-OS sei più al sicuro, perché “tanti occhi guardano il codice” e non dipendi dai tempi di un vendor.
Il mito, messo alla prova dai fatti di luglio
La sequenza di luglio dice l’esatto contrario di quel mito, e vale la pena guardarla con ordine. La vulnerabilità critica non l’ha trovata la community open source: l’ha trovata (o l’ha ricevuta in responsible disclosure) Adobe, che l’ha analizzata, patchata e pubblicata nel suo bollettino. Mage-OS non ha scoperto niente di suo su quel fronte: ha preso la patch di Adobe, isolata dal resto del changeset commerciale, e l’ha rilasciata sulla propria base in poche ore. È un lavoro fatto bene, lo dico senza ironia: isolare una patch di sicurezza da un ramo che altrimenti trascina anche modifiche commerciali non banali è un esercizio delicato, e Mage-OS lo fa da anni con una disciplina che rispetto. Ma è manutenzione su un problema che qualcun altro ha trovato, non prevenzione indipendente.
Detto questo, sarei ingeneroso a fermarmi qui: nella stessa release, Mage-OS ha risolto anche un bug tutto suo, non ereditato da Adobe, una falla nel carrello ospite che permetteva, con un ID mascherato, di raggiungere il carrello di un cliente autenticato. Quella l’hanno trovata loro. È un problema meno grave del CVE 10.0 di Adobe, ma è la prova che la capacità di trovare vulnerabilità in autonomia c’è, non è teatro. Il punto resta: sulle vulnerabilità di livello critico che contano davvero, la fonte primaria oggi è ancora il vendor commerciale, non il fork.
Qui la mia posizione è netta, e so che non farà piacere a chi si è convertito all’open source aspettandosi di lasciarsi alle spalle anche i problemi di sicurezza insieme alla licenza: la scoperta delle vulnerabilità più gravi su questo stack continua a passare per Adobe, non per la community. Il valore di Mage-OS in questa storia non è “trovare prima”, è “distribuire più in fretta, senza aspettare la finestra di rilascio commerciale”. Sono due cose diverse, e confonderle porta a scelte di sicurezza sbagliate.
Il contro-argomento che tengo in piedi
Il punto a favore dell’open source, in questa vicenda, però regge, e sarebbe disonesto negarlo: la velocità di distribuzione. Mage-OS ha rilasciato la patch isolata lo stesso giorno del bollettino Adobe. Su un’installazione Adobe Commerce on-premise, invece, la patch va applicata a mano, e nella mia esperienza tra la pubblicazione del bollettino e l’effettiva applicazione in produzione passano giorni, a volte più di una settimana, perché nel mezzo c’è un test di regressione da fare, un cliente da avvisare, una finestra di manutenzione da negoziare.
Ho gestito, qualche mese fa, il caso di un merchant enterprise (~40M di GMV, catalogo complesso, molte customizzazioni) dove un bollettino critico simile ha richiesto cinque giorni tra pubblicazione e patch in produzione: non per pigrizia, ma perché su un’installazione con quel livello di personalizzazione ogni patch di sicurezza va testata prima di essere promossa, altrimenti rischi di sostituire un incidente di sicurezza con un incidente operativo. Su un’installazione Mage-OS più vicina allo standard, quella finestra si accorcia, perché c’è meno customizzazione da verificare.
Cosa conta davvero, secondo me
Quindi no, non credo che la piattaforma sia la variabile che decide quanto sei esposto. La variabile è la disciplina di patching, e quella dipende da te, non dal logo sulla licenza. Un’installazione Adobe Commerce con un processo di aggiornamento serio (monitoraggio dei bollettini, ambiente di staging pronto, finestra di manutenzione concordata in anticipo con il cliente, non negoziata sul momento) chiude una CVE critica più in fretta di un’installazione Mage-OS lasciata a sé stessa per mesi. E viceversa: uno store open source curato bene batte in velocità un Commerce on-premise gestito con leggerezza. L’ho visto in entrambe le direzioni.
Quello su cui invece do ragione a chi difende l’open source è un punto strutturale: meno personalizzazione significa patch più rapide da verificare, a prescindere dalla piattaforma. Se il tuo store è molto customizzato, la sicurezza costa tempo di test, non solo tempo di applicazione. È un argomento a favore della semplicità architetturale, più che a favore di una licenza specifica.
Il consiglio pratico, tolta la teoria
Non è un tema nuovo per chi mi legge da un po’: ne scrivevo già ai tempi della fine del supporto a Magento 1, quando la domanda che contava era la stessa di oggi, solo con un altro nome in testa al bollettino.
Se gestisci un negozio su Adobe Commerce o Mage-OS, la domanda giusta da farti dopo un bollettino come APSB26-73 non è “sono sulla piattaforma giusta”, è “quanti giorni impiego, davvero, tra la pubblicazione di una CVE critica e la patch in produzione, e cosa rallenta quel processo”. Se la risposta è “non lo so”, quello è il problema da risolvere prima di qualunque discussione su quale fork usare.
Meno tifoseria tra piattaforme, più misurazione del proprio tempo di reazione. Vale per la sicurezza come vale, mi rendo conto, per quasi tutto quello di cui scrivo qui.
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.