Il 24 settembre 2026 la CISA ha aggiunto al catalogo Known Exploited Vulnerabilities la CVE-2026-71362, una falla critica di Adobe Commerce e Magento Open Source che permette a un attaccante non autenticato di prendere il controllo dell'account di un cliente del negozio online. La patch è disponibile dall'11 agosto, ma l'inserimento nel KEV certifica ciò che i ricercatori segnalavano già da settimane: la vulnerabilità viene sfruttata davvero.

Per chi gestisce un e-commerce su Magento è il secondo campanello d'allarme in un mese. A inizio settembre avevamo raccontato StyleSmuggler, la RCE sfruttata come zero-day: nel frattempo ha ricevuto l'identificativo CVE-2026-75650 (CVSS 10) e una correzione d'emergenza di Adobe (APSB26-146) rilasciata il 7 settembre sotto forma di hotfix. Sono due falle diverse, con due patch diverse: aver applicato l'una non protegge dall'altra.

I fatti verificati

  • Identificativo: CVE-2026-71362, bollettino Adobe APSB26-92 dell'11 agosto 2026.
  • Gravità: CVSS 3.1 9.1, critica. Vettore di rete, bassa complessità, nessun privilegio e nessuna interazione dell'utente richiesti.
  • Natura del difetto: autorizzazione non corretta (CWE-863). Analizzando la patch, la società olandese Sansec ha stabilito che il problema risiede nella gestione dell'identità del cliente all'interno della sessione: un attaccante può spostare una sessione su un altro account cliente, accedendo ai dati personali della vittima.
  • Versioni colpite: Adobe Commerce dalla 2.4.4 alla 2.4.9, Adobe Commerce B2B dalla 1.3.3 alla 1.5.3, Magento Open Source dalla 2.4.6 alla 2.4.9, fino alle release di sicurezza di luglio 2026 incluse.
  • Sfruttamento: Sansec ha bloccato i primi tentativi con il proprio WAF già a ridosso della pubblicazione; telemetria di terze parti ha registrato ulteriori tentativi il 10 settembre. Adobe, al momento in cui scriviamo, non ha aggiornato il bollettino per confermare lo sfruttamento, ma la presenza nel KEV è un segnale sufficiente per trattarla come priorità.
  • Stesso bollettino, altre falle: APSB26-92 corregge sette vulnerabilità, tra cui due XSS memorizzati ad alta gravità (CVE-2026-48413 e CVE-2026-48414) e un bypass di autorizzazione non autenticato (CVE-2026-48416, CVSS 7.5).

Il vero problema: come arrivano le patch

C'è un dettaglio operativo che spiega perché, sei settimane dopo, molti negozi sono ancora vulnerabili. Come sottolineato da Sansec, le correzioni mensili di Adobe per Magento vengono distribuite come file di patch isolati, non come una nuova release né come pacchetti Composer aggiornati. Per applicarle bisogna prima essere sull'ultima release "-p" disponibile per il proprio ramo e poi installare la patch specifica.

Tradotto: chi aggiorna Magento solo tramite composer update, o chi si affida a un'agenzia che interviene "a chiamata", può credere di essere in regola senza esserlo. Lo stesso vale per l'hotfix di StyleSmuggler, distribuito anch'esso come patch Composer separata. In un ecosistema come quello italiano, dove molti e-commerce di PMI sono stati sviluppati da agenzie e poi lasciati con contratti di manutenzione minimi, questo meccanismo è un moltiplicatore di rischio.

Cosa significa per le aziende italiane

Magento resta una delle piattaforme più diffuse per l'e-commerce di fascia media in Italia, soprattutto nella moda, nell'arredo, nell'alimentare e nel B2B distributivo. A differenza di StyleSmuggler, CVE-2026-71362 non consegna il server all'attaccante: consegna gli account dei clienti. Il che, dal punto di vista normativo, è persino più immediato.

  • È una violazione di dati personali: nome, indirizzi, storico ordini, telefono, eventuali dati di fatturazione. Se ci sono indizi di sfruttamento, il titolare deve valutare la notifica al Garante entro 72 ore (art. 33 GDPR) e, se il rischio per le persone è elevato, la comunicazione diretta ai clienti (art. 34).
  • Il rischio non si ferma alla privacy: un account cliente compromesso permette ordini fraudolenti verso indirizzi diversi, uso di credito o punti fedeltà, cambio dell'email di contatto e phishing mirato con dati reali. Nei portali B2B, dove un account può avere condizioni di pagamento dilazionato, il danno economico è diretto.
  • La responsabilità resta al titolare: se l'e-commerce è gestito da un'agenzia, questa è con ogni probabilità responsabile del trattamento ai sensi dell'art. 28. Ma davanti al Garante è il titolare a dover dimostrare di aver adottato misure adeguate (art. 32): "l'agenzia non ci aveva avvisato" non è una misura di sicurezza.
  • Aziende in perimetro NIS2: per i soggetti del commercio e della distribuzione rientranti nel perimetro, una compromissione su larga scala degli account può configurare un incidente significativo da notificare al CSIRT Italia.

Cosa fare subito

  • Verificare la versione esatta del negozio e se sono installate le patch isolate di agosto 2026 (APSB26-92) e l'hotfix di settembre (APSB26-146, StyleSmuggler). Non basta il numero di versione: controllare che le patch risultino effettivamente applicate.
  • Chiedere per iscritto all'agenzia o al fornitore di hosting conferma di entrambe le patch, con data di applicazione.
  • Analizzare i log da metà agosto in avanti alla ricerca di cambi anomali di email o password degli account, accessi da IP insoliti seguiti da modifiche al profilo, ordini verso indirizzi di spedizione nuovi.
  • Invalidare le sessioni attive dopo la patch e, se emergono anomalie, forzare il reset delle password dei clienti coinvolti.
  • Attivare un WAF con regole specifiche per Magento, come misura di difesa in profondità e non come sostituto della patch.
  • Predisporre il fascicolo della violazione nel registro interno (art. 33, par. 5) anche se si conclude che la notifica non è dovuta: la valutazione va documentata.