Una falla da 10 su 10 in Magento e Adobe Commerce: cosa è successo davvero

Prima la risposta diretta: il 4 settembre 2026 alcuni attaccanti hanno iniziato a sfruttare una falla non corretta in Magento Open Source e Adobe Commerce, registrata come CVE-2026-75650 con un punteggio di gravità di 10.0, il massimo possibile. La falla consente di eseguire comandi sul server del negozio senza login e senza alcun privilegio, e Adobe ha rilasciato la correzione la sera del 7 settembre. Restano quindi tre giorni interi durante i quali i negozi sono stati esposti senza alcuna protezione. È proprio per questo che installare la patch non basta: se il tuo negozio gira su questa piattaforma, l'ipotesi prudente è che tu possa essere stato compromesso prima che la correzione esistesse, e la risposta giusta è cercare segni di intrusione e ruotare le chiavi di cifratura e ogni credenziale, non installare l'aggiornamento e passare oltre.

Chi è colpito, esattamente

L'elenco è insolitamente ampio, perché comprende la versione più recente disponibile al momento della scoperta:

  • Magento Open Source e Adobe Commerce: versioni dalla 2.4.4 alla 2.4.9, inclusi tutti gli aggiornamenti di patch fino ad agosto 2026.
  • Adobe Commerce B2B: versioni dalla 1.3.3 alla 1.5.3, fino all'aggiornamento di agosto 2026.
  • Tutto ciò che è precedente alla 2.4.4: già fuori supporto, ed è la categoria più pericolosa perché l'hotfix ufficiale non la copre.

Detto in modo semplice: se al 1 settembre usavi un Magento completamente aggiornato, eri esposto. Non è il solito scenario di negligenza da cui di solito mettiamo in guardia: è un vero zero-day che nessuno aveva modo di anticipare.

Come funziona l'attacco senza password

L'attacco si svolge in due fasi e sfrutta la capacità di Magento di costruire modelli di email. Nella prima fase, l'attaccante invia una richiesta costruita ad arte a un percorso di risposta dei pagamenti, e l'intero contenuto di quella richiesta viene scritto in un file di report degli errori sul server. Nella seconda fase, una richiesta all'endpoint GraphQL punta di nuovo a quel file avvelenato, e il suo contenuto viene eseguito mentre si prepara un'email di promemoria per pagamento non riuscito.

Ciò che merita l'attenzione di un imprenditore non è il dettaglio tecnico, ma ciò che rivela: percorsi pubblici dall'aspetto del tutto innocuo (la risposta di un gateway di pagamento, un endpoint di interrogazione per la vetrina, un'email automatica) combinati in un percorso completo verso il server. Le vulnerabilità gravi raramente sono un'unica porta spalancata; molto più spesso sono una catena di piccole porte, ognuna delle quali da sola sembra perfettamente ragionevole.

Cosa hanno piazzato gli attaccanti una volta dentro

È qui che si vede la differenza tra un vandalo e un'operazione organizzata. I payload osservati non erano rumorosi messaggi di ransomware, ma silenziosi strumenti di persistenza:

  • Una backdoor scritta in Rust che si maschera da uno dei processi del kernel del sistema operativo, così da non dare nell'occhio a chi scorre velocemente l'elenco dei processi.
  • Traffico di comando e controllo camuffato sulla porta di sincronizzazione dell'orario, in modo che l'attività sembri, nei log di rete, una normale regolazione dell'orologio.
  • Web shell PHP scritte nelle cartelle di cache delle immagini dei prodotti, luoghi che di norma nessuno controlla perché pieni di file temporanei.
  • Ulteriori strumenti di accesso remoto di un secondo attaccante con strumenti non correlati, il che significa che la falla veniva sfruttata da più di un gruppo contemporaneamente.

Lo scopo di payload del genere su un negozio online noto è restare a lungo e leggere i dati di ordini e pagamenti mentre transitano, non mettere fuori uso il sito. Un negozio infetto continua a funzionare in modo del tutto normale, ed è proprio questo l'aspetto inquietante.

Perché installare l'aggiornamento non basta

Perché se un attaccante è entrato prima del 7 settembre, ora possiede una copia delle tue chiavi di cifratura e delle credenziali memorizzate. La patch chiude la porta da cui è entrato; non lo caccia da dentro. Le indicazioni stesse di Adobe sono state esplicite su questo punto: applicare la correzione e poi ruotare le chiavi di cifratura, le password del pannello di amministrazione, i token API, le credenziali del gateway di pagamento, le password del database e le chiavi di accesso al server.

La patch ferma l'emorragia. Ruotare le chiavi è ciò che fa uscire di casa l'ospite indesiderato.

Un piano d'azione pratico per il titolare di un negozio

  • Primo: verifica che la correzione sia davvero installata, non che qualcuno abbia detto che lo è. Chiedi al tuo team una prova dal log delle patch sul server stesso, non un messaggio rassicurante.
  • Secondo: cerca tracce di intrusione: processi in esecuzione sospetti con nomi che imitano processi di sistema, file PHP nelle cartelle di media e immagini e file di report degli errori insoliti.
  • Terzo: controlla il log delle email in uscita. Un picco improvviso di email di promemoria per pagamento non riuscito è un indicatore diretto di tentativi di sfruttamento, e qualsiasi responsabile delle operazioni può leggerlo senza competenze approfondite di sicurezza.
  • Quarto: ruota ogni chiave senza eccezioni, prima di tutto le credenziali del gateway di pagamento. Serve una finestra di manutenzione pianificata, non una decisione improvvisata nelle ore di punta.
  • Quinto: se la tua versione è precedente alla 2.4.4, smetti di aspettare una patch ufficiale che non arriverà. Stabilisci un piano di aggiornamento con una data reale e, nel frattempo, metti il negozio dietro un web application firewall.
  • Sesto: documenta ciò che hai fatto. Se dovesse emergere che i dati dei clienti sono trapelati, ti servirà una cronologia di cosa hai fatto e quando.

L'aspetto normativo in Arabia Saudita: i dati dei clienti non sono solo una questione tecnica

Un negozio online che conserva nomi, indirizzi, numeri di cellulare e storico degli ordini dei clienti tratta dati personali disciplinati dalla Legge sulla protezione dei dati personali. Una violazione non resta una questione interna tra il negozio e il suo provider di hosting; crea obblighi verso l'autorità competente e verso gli stessi interessati. Per questo la domanda che il titolare di un negozio dovrebbe porsi oggi non è solo "il server ha la patch?", ma "posso dimostrare che i dati dei miei clienti non sono stati toccati?".

Se il tuo negozio gira su una piattaforma cloud gestita come Salla o Zid, sei fuori dal perimetro di questa specifica falla, perché applicare le patch alla piattaforma non è una tua responsabilità. Ma la stessa lezione vale per qualsiasi estensione o integrazione di terze parti che hai collegato al tuo negozio: la responsabilità delle patch segue chi possiede il server.

Come gestiamo incidenti del genere in Origami

Il principio su cui costruiamo i sistemi dei clienti è che un incidente di sicurezza non è una possibilità remota ma un evento rimandato. In pratica significa tre cose: credenziali tenute fuori dal codice, in un vault separato, così che ruotarle sia un lavoro di minuti e non un progetto di una settimana; log operativi conservati fuori dal server stesso, così che un attaccante non possa cancellare le proprie tracce; e backup effettivamente testati ripristinandoli, non semplicemente pianificati.

E se gestisci un negozio Magento senza un team tecnico dedicato, la mossa corretta oggi è semplice: chiedi al tuo provider di hosting o partner tecnico un report scritto che risponda solo a tre domande: quando esattamente è stata installata la correzione, cosa ha trovato l'analisi di compromissione e se le chiavi sono state ruotate. Queste tre domande rivelano sulla preparazione di un partner tecnico più di qualsiasi presentazione.

Fonti

  • Annuncio ufficiale di Adobe Commerce sull'aggiornamento di sicurezza APSB26-146 e sull'hotfix urgente: experienceleague.adobe.com
  • Analisi tecnica di Sansec sulla CVE-2026-75650 e sugli indicatori di compromissione: sansec.io/research/stylesmuggler-0day
  • Catalogo CISA delle vulnerabilità sfruttate note: cisa.gov
  • Legge sulla protezione dei dati personali (PDPL) — Autorità saudita per i dati e l'intelligenza artificiale (SDAIA): sdaia.gov.sa