Adobe Commerce e Magento sotto attacco: la falla che espone gli account dei tuoi clienti
CVE-2026-71362 è una vulnerabilità di autorizzazione errata (CWE-863) in Adobe Commerce e Magento Open Source che permette a un attaccante remoto, senza alcuna autenticazione, di far scivolare la propria sessione su un account cliente altrui. Non serve una password rubata, non serve un account di partenza: basta raggiungere il negozio online come farebbe un qualunque visitatore. Con un punteggio CVSS di 9.1, è tra le falle più gravi mai emerse sulla piattaforma e riguarda in modo diretto chiunque gestisca un e-commerce, non solo i grandi marketplace: la base installata di Magento comprende moltissimi negozi di piccole e medie dimensioni.
Indice
- Il meccanismo: sessioni non legate correttamente all'identità
- Timeline della disclosure
- Versioni coinvolte
- Sfruttamento in corso
- Come verificare se il tuo negozio è a rischio
- Cosa fare oltre alla patch
- Perché conviene anche a chi ha un piccolo shop online
- Risorse
Il meccanismo: sessioni non legate correttamente all'identità
Ogni volta che un cliente accede al proprio account su un negozio Magento, il sistema crea una sessione e la associa a quel cliente specifico: è quel legame che permette al backend di sapere, richiesta dopo richiesta, "questa sessione appartiene a Mario Rossi" e quindi di mostrargli i suoi ordini, il suo indirizzo, i suoi metodi di pagamento salvati. CVE-2026-71362 nasce da un difetto proprio in quel legame: Sansec, la società che ha analizzato la patch di Adobe, ha individuato che Commerce e Magento non verificano correttamente la corrispondenza tra la sessione attiva e l'identità del cliente a cui dovrebbe appartenere. Un attaccante può sfruttare questo difetto per far passare la propria sessione da un account a un altro, ottenendo di fatto l'accesso ai dati e alla cronologia ordini di un cliente qualunque senza averne le credenziali.
Quello che rende la falla particolarmente critica è l'assenza di qualunque precondizione. Adobe conferma che non serve autenticazione, non servono privilegi da amministratore, non serve alcuna interazione da parte della vittima: è sufficiente il normale accesso di rete allo store, lo stesso che ha qualunque visitatore che apre la pagina del negozio. È il tipo di difetto che nella pratica trasforma un singolo endpoint mal progettato in un accesso diretto a dati personali, cronologia acquisti e potenzialmente ai metodi di pagamento salvati di migliaia di clienti in un colpo solo.
Timeline della disclosure
| Data | Evento |
|---|---|
| luglio 2026 | le build -2026-jul di Adobe Commerce e Magento Open Source risultano vulnerabili, insieme a tutte le versioni precedenti supportate. |
| 11 agosto 2026 | Adobe pubblica il bollettino APSB26-92 e rilascia le build -2026-aug con la correzione, insieme ad altre sei patch di sicurezza distribuite come fix isolati per velocizzare l'adozione. |
| giorni successivi | Sansec rileva i primi tentativi di sfruttamento contro store non ancora aggiornati, bloccati dai propri sistemi di protezione. |
Adobe dichiara di non essere a conoscenza di exploit pubblici al momento della disclosure, ma la finestra tra pubblicazione dell'advisory e comparsa dei primi tentativi reali è stata, come spesso accade ormai, di pochi giorni.
Versioni coinvolte
| Prodotto | Versioni vulnerabili | Versione con la patch |
|---|---|---|
| Adobe Commerce | 2.4.4 - 2.4.9 (build -2026-jul e precedenti) |
build -2026-aug |
| Magento Open Source | 2.4.6 - 2.4.9 (build -2026-jul e precedenti) |
build -2026-aug |
| Adobe Commerce B2B | 1.3.3 - 1.5.3 | build -2026-aug |
Praticamente ogni installazione attiva e supportata rientra in uno di questi intervalli: non è una falla che riguarda solo versioni vecchie o dismesse.
Sfruttamento in corso
A differenza di altre falle che restano teoriche per settimane dopo la disclosure, qui i tentativi di sfruttamento sono arrivati quasi subito. Sansec, che monitora il traffico verso migliaia di installazioni Magento tramite la propria rete di sensori, ha osservato scansioni e tentativi di exploitation nei giorni immediatamente successivi alla pubblicazione della patch, segno che chi analizza i diff di sicurezza per ricavarne exploit funzionanti ha ormai tempi di reazione molto ridotti. Il fatto che l'attacco non richieda credenziali di partenza lo rende inoltre facilmente automatizzabile su larga scala, a differenza di falle che presuppongono un account già compromesso.
Come verificare se il tuo negozio è a rischio
Il primo controllo è la versione installata. Da riga di comando, sul server dove gira l'installazione:
php bin/magento --version
Se il numero riportato rientra in uno degli intervalli vulnerabili della tabella sopra, l'aggiornamento va programmato subito, dando priorità agli store con checkout attivo e traffico reale rispetto a ambienti di staging o demo. Chi usa Adobe Commerce Cloud riceve la patch attraverso il normale processo di deployment gestito; chi ospita Magento Open Source in autonomia deve applicare la build -2026-aug (o il fix isolato, se preferisce non aggiornare l'intero stack in un solo passaggio) tramite Composer, seguendo la procedura di aggiornamento standard di Adobe.
Un dettaglio spesso trascurato: l'inventario da controllare non è solo il sito di produzione. Ambienti di staging, siti di campagna promozionale e installazioni di test esposte pubblicamente sono altrettanto raggiungibili da un attaccante e vanno censiti e aggiornati con la stessa priorità, anche se non generano fatturato diretto.
Cosa fare oltre alla patch
Applicare la patch chiude la falla per il traffico futuro, ma non annulla l'eventuale sfruttamento già avvenuto prima dell'aggiornamento. Sansec segnala che una protezione WAF mirata sugli endpoint di sessione e di gestione cliente sta già bloccando parte dei tentativi in corso, ed è una misura sensata da mantenere attiva anche dopo la patch, come ulteriore strato.
Vale la pena anche invalidare le sessioni cliente attive subito dopo l'aggiornamento: se una sessione era già stata dirottata prima della patch, il solo fix del codice non la interrompe automaticamente. Controllare i log applicativi alla ricerca di pattern anomali, come cambi di account associati a una stessa sessione o accessi a dati di clienti diversi da IP che si susseguono in rapida sequenza, aiuta a capire se lo store è stato tra i bersagli prima ancora di trovare conferme più dirette. Su store che mostrano segnali sospetti, meglio verificare anche l'eventuale presenza di codice non autorizzato caricato nel frattempo: un account cliente compromesso è un punto di accesso, non necessariamente il punto di arrivo di chi lo sfrutta.
Perché conviene anche a chi ha un piccolo shop online
Magento e Adobe Commerce vengono spesso associati a grandi marketplace enterprise, ma buona parte delle installazioni reali sono negozi di dimensioni medio-piccole gestiti con budget IT limitati, a volte senza un team dedicato che segua gli advisory di sicurezza appena escono. È proprio questo profilo il più esposto: un attacco che non richiede credenziali né interazione dell'utente non fa distinzioni tra un e-commerce con milioni di clienti e uno con qualche centinaio di ordini al mese, colpisce ovunque trovi una versione non aggiornata. Per chi vende online, i dati in gioco (indirizzi, cronologia acquisti, in alcuni casi metodi di pagamento salvati) sono esattamente il tipo di informazione la cui esposizione comporta obblighi di notifica secondo il GDPR, oltre al danno reputazionale verso i propri clienti.
Tenere traccia degli advisory di sicurezza della piattaforma su cui gira il proprio negozio, anche quando non si dispone di un reparto IT strutturato, dovrebbe avere la stessa priorità del monitoraggio delle vendite: una violazione di questo tipo, una volta resa pubblica, pesa sulla fiducia dei clienti molto più a lungo di quanto costi applicare una patch il giorno stesso in cui esce.