Zero-day su Adobe Commerce: patch in ore, non in settimane

Il 4 settembre 2026 gli attaccanti hanno iniziato a sfruttare una falla di Adobe Commerce che nessuno conosceva ancora. La correzione d'emergenza è arrivata il 7; il bollettino mensile dell'8 ha aggiunto otto vulnerabilità critiche. Un mese dopo, l'episodio merita una rilettura a freddo — meno per i numeri dei CVE che per ciò che rivela della tua organizzazione: il tempo che passa tra la pubblicazione di una patch e la sua applicazione è diventato una metrica di sopravvivenza.

Tre giorni di vantaggio per gli attaccanti

Prima la cronologia. La campagna, battezzata StyleSmuggler da Sansec, è partita il 4 settembre: diversi gruppi stavano già piazzando backdoor e webshell abusando di un'iniezione nel motore dei template, innescata tramite una normale e-mail transazionale — il promemoria di pagamento non riuscito — senza alcuna azione della vittima (il resoconto di SecurityWeek). Adobe ha reagito il 7 settembre con una correzione fuori ciclo, il bollettino APSB26-146: la falla CVE-2026-75650 ha il punteggio CVSS massimo di 10,0 e consente l'esecuzione di codice da remoto senza autenticazione. Sono interessati Adobe Commerce dalla 2.4.4 alla 2.4.9, Magento Open Source dalla 2.4.6 alla 2.4.9 e l'estensione B2B dalla 1.3.3 alla 1.5.3 — in pratica quasi tutto il parco installato, anche aggiornato ad agosto.

Il giorno dopo, il bollettino mensile APSB26-138 correggeva altre otto falle, tutte classificate critiche: due XSS memorizzati con punteggio 9,3, cinque difetti di autorizzazione, un attraversamento di directory. Sei su otto si sfruttano senza alcun account.

La trappola delle due patch

Un dettaglio operativo conta: la correzione d'emergenza non fa parte del treno mensile. Adobe precisa che si installa separatamente — applicare il livello di settembre senza l'hotfix lascia aperta l'unica falla attivamente sfruttata, e l'hotfix da solo non copre le altre otto. Dal 2026 le patch raggruppate escono ogni mese e vengono denominate per data (2.4.9-2026-sep, per esempio) invece che con i numeri p. Più leggibile — ma presuppone che qualcuno, nel tuo team o dal tuo integratore, legga davvero i bollettini e sappia distinguere un hotfix prioritario da una scadenza di routine.

La finestra si è chiusa

Stessa stagione, l'anno scorso: SessionReaper (CVE-2025-54236), corretta il 9 settembre 2025. I primi attacchi di massa hanno atteso sei settimane; in quel momento solo il 38% dei negozi era aggiornato, e le ondate automatizzate hanno finito per prendere di mira più di un negozio su due nel mondo, secondo i numeri pubblicati allora da Sansec. Nel 2026 il copione si è invertito: lo sfruttamento ha preceduto la correzione di tre giorni. La conclusione è dura ma semplice — «mettiamo la patch nel prossimo sprint» non è più una politica di sicurezza: è una scommessa contro avversari automatizzati.

Cosa impone alla tua organizzazione

Tre conseguenze molto concrete, viste dalla poltrona dell'architetto:

• Uno SLA delle patch per iscritto. Hotfix attivamente sfruttato: applicazione in ore. Bollettino critico: in giorni. Dai un nome a chi legge i bollettini, chi decide, chi applica, chi verifica — una patch senza responsabile aspetta sempre.
• Un'architettura che rende la patch economica. Un ambiente di staging fedele alla produzione, test automatizzati dei percorsi d'acquisto, deployment ripetibili e senza interruzioni. Il vero costo di una patch è la paura di rompere qualcosa; quella paura si costruisce — o si smonta — nell'architettura.
• Quanto basta per reggere le prime ore. Un firewall applicativo davanti all'admin e alle API, il monitoraggio dell'integrità dei file, una revisione regolare degli account amministratore. E dopo uno zero-day sfruttato, la patch non basta: cerca le tracce di una visita precedente alla correzione — webshell, account sconosciuti, attività pianificate, moduli modificati.

La checklist di ottobre

• Registra il livello di patch esatto di ogni ambiente, estensione B2B compresa: se è anteriore a settembre 2026, sei esposto.
• Verifica che l'hotfix per CVE-2026-75650 sia applicato ovunque — produzione, pre-produzione, ambienti demo raggiungibili da internet.
• Fai ispezionare ogni negozio rimasto vulnerabile dopo il 4 settembre come se fosse stato visitato: lo sfruttamento è iniziato prima che la correzione esistesse.
• Scrivi lo SLA, poi cronometrati sul treno di ottobre: è l'esercitazione in scala reale più economica sul mercato.

Un bollettino di sicurezza è, in fondo, un test gratuito della tua catena di consegna. Le organizzazioni che distribuiscono una patch in poche ore hanno un'architettura e una governance sane; quelle che impiegano settimane scoprono, un settembre o l'altro, che il debito tecnico si paga anche in incidenti di sicurezza.