PolyShell, la falla dei negozi Magento è sfruttata attivamente secondo la CISA: cosa deve controllare chi vende online

PolyShell, la falla dei negozi Magento è sfruttata attivamente secondo la CISA: cosa deve controllare chi vende online

Informazioni aggiornate al 28 ottobre 2026, ore 8:54 (ora di Roma).

In breve

  • Il 27 ottobre 2026 la CISA ha inserito CVE-2026-48356 (PolyShell) nel catalogo KEV.
  • La correzione esiste dal 14 luglio 2026 (APSB26-73): release “2026-jul” e Commerce Events 1.21.0.
  • Il bollettino di Adobe, aggiornato l’ultima volta l’11 agosto, dice ancora di non conoscere exploit in circolazione: è precedente all’inserimento nel KEV.
  • Chi non ha aggiornato in tempo deve anche verificare file caricati, blocchi CMS, account e, se serve, cambiare le password.

Che cosa è cambiato il 27 ottobre

Il 27 ottobre la CISA, l’agenzia statunitense per la sicurezza informatica e delle infrastrutture, ha aggiunto CVE-2026-48356 al catalogo KEV (Known Exploited Vulnerabilities), l’elenco delle vulnerabilità per le quali esistono prove di sfruttamento attivo. È una falla di Adobe Commerce e Magento che permette di caricare sul server file di tipo pericoloso senza restrizioni.

Secondo la scheda del catalogo, la falla può portare all’esecuzione di codice arbitrario e potenzialmente al controllo dell’account o della sessione della vittima; nel bollettino Adobe ne classifica l’impatto come scalata di privilegi. Le agenzie federali civili statunitensi hanno tempo fino al 10 novembre 2026 per applicare le correzioni; alla voce sull’uso in campagne ransomware il catalogo indica “Unknown”, cioè non noto. L’obbligo riguarda solo le agenzie federali, ma la CISA invita tutte le organizzazioni a dare priorità alle vulnerabilità del catalogo.

Una correzione disponibile da luglio

Adobe ha corretto la falla il 14 luglio 2026 con il bollettino APSB26-73, che risolve in tutto quattordici vulnerabilità e ha priorità 2. Per CVE-2026-48356 Adobe indica gravità critica, nessuna autenticazione necessaria e, nel bollettino, un punteggio CVSS 3.1 di 9,6; il record ufficiale della CVE, aggiornato dalla stessa Adobe, e la scheda NVD riportano invece 9,3. Le due valutazioni differiscono per un solo parametro, l’impatto sulla disponibilità del servizio.

Per questa falla Adobe indica come interessate le versioni di Adobe Commerce 2.4.9, 2.4.8-p5, 2.4.7-p10, 2.4.6-p15, 2.4.5-p17 e 2.4.4-p18 con le precedenti di ciascun ramo, e le versioni di Magento Open Source 2.4.9, 2.4.8-p5, 2.4.7-p10 e 2.4.6-p15 con le precedenti. Sono coinvolti anche Adobe Commerce B2B e Adobe Commerce Events. Le versioni corrette sono le release contrassegnate “2026-jul” (per esempio 2.4.8-2026-jul) e, per Commerce Events, la 1.21.0. Anche chi usa la 2.4.9 deve quindi installare la release 2.4.9-2026-jul.

In Italia l’Agenzia per la cybersicurezza nazionale aveva segnalato gli aggiornamenti in un avviso del 15 luglio, aggiornato il 28 settembre per indicare che per CVE-2026-48356 è disponibile un proof of concept, cioè un exploit dimostrativo.

«Nessun exploit noto»: una frase da leggere con la sua data

Il bollettino di Adobe, aggiornato l’ultima volta l’11 agosto 2026, afferma ancora che l’azienda non è a conoscenza di exploit in circolazione per le vulnerabilità corrette. Quella frase, in base alla data indicata sulla pagina, è precedente all’inserimento nel catalogo KEV del 27 ottobre; alla verifica del 28 ottobre la pagina era invariata. Già a marzo Sansec riferiva di attacchi in corso.

Che cosa riferisce Sansec: attacchi da marzo e una campagna sui blocchi CMS

PolyShell è il nome dato alla falla da Sansec, azienda olandese specializzata nella sicurezza dell’e-commerce, che afferma di averla scoperta e l’ha resa pubblica il 17 marzo 2026. Secondo Sansec, chiunque, senza login, può caricare file sul negozio attraverso le funzioni del carrello per utenti ospiti dell’interfaccia REST: file che sembrano immagini ma contengono codice PHP. L’azienda riferisce attacchi automatizzati di massa a partire da marzo e, nei negozi compromessi, l’installazione di una backdoor chiamata accesson.php, copiata in più cartelle per resistere alle pulizie.

Il 24 ottobre Sansec ha collegato PolyShell a una campagna attiva da luglio 2025, che inserisce un piccolo programma JavaScript (un loader) nei blocchi CMS, i contenuti statici che Magento mostra nelle pagine del negozio. Secondo i dati dell’azienda la campagna, che cambia dominio ogni pochi mesi, ha colpito 953 negozi; il dominio più recente, comparso a ottobre, è stato trovato su 83 negozi. Sansec attribuisce a PolyShell l’ondata di marzo, quando il loader è stato inserito in 471 negozi in un’ora; per le altre fasi parla di falle nel caricamento di file di Magento.

Secondo Sansec il loader distingue i veri clienti dagli scanner di sicurezza e l’azienda non ha ancora recuperato il contenuto finale servito ai visitatori. Inoltre, chi ha installato il loader può scrivere nel database del negozio, e cancellare lo script non elimina questo accesso. Sansec segnala anche un negozio che, secondo i suoi controlli, non aveva patch del core mancanti e ha ricevuto comunque il loader: era già stato compromesso nelle settimane precedenti.

I numeri di Sansec sono dati di telemetria di un’azienda che vende prodotti di protezione, non dati ufficiali; le fonti non forniscono cifre sull’Italia.

Cosa controllare oggi su un negozio Magento o Adobe Commerce

Chi non è un tecnico può girare questo elenco all’agenzia o all’hosting.

  • Conoscere la versione esatta. Chiedere quale versione di Adobe Commerce o Magento è in uso e se è installato l’aggiornamento APSB26-73, cioè una release “2026-jul” o, per Commerce Events, la 1.21.0. Se manca, va installato: Adobe raccomanda di aggiornare all’ultima versione.
  • Non fermarsi all’aggiornamento. La patch impedisce nuovi attacchi attraverso questa falla, ma non rimuove ciò che fosse già stato caricato: secondo Sansec, i file caricati restano sul server anche quando non possono essere eseguiti.
  • Far controllare i file caricati. Sansec indica di verificare la cartella dei caricamenti pub/media/custom_options/ e di cercare la backdoor accesson.php nel resto del sito.
  • Far controllare i contenuti e gli accessi. Secondo Sansec vanno esaminati i blocchi e le pagine CMS, alla ricerca di script non riconosciuti, insieme agli account di amministrazione sconosciuti e ai processi insoliti sul server. Sansec spiega anche che la data dell’ultima modifica dei blocchi interessati indica l’ultimo intervento dell’attaccante.
  • Se si trova qualcosa. Dopo la pulizia, Sansec consiglia di cambiare le password del database, dell’amministrazione e delle integrazioni API.

Lo stesso principio di PHP2Shell

Come nel caso di PHP2Shell, le falle critiche di PHP di cui abbiamo scritto il 23 ottobre, la protezione passa dall’aggiornamento del software su cui il sito si regge. Quando una falla risulta sfruttata, però, bisogna anche verificare che nessuno sia già entrato.

Domande frequenti

1. Che cos’è PolyShell?

È il nome dato da Sansec, che afferma di averla scoperta, alla vulnerabilità CVE-2026-48356 di Adobe Commerce e Magento, resa pubblica il 17 marzo 2026. Permette di caricare sul server file di tipo pericoloso senza restrizioni; secondo Sansec, chiunque, senza login, può caricare file che sembrano immagini ma contengono codice PHP.

2. Che cosa è cambiato il 27 ottobre 2026?

La CISA ha aggiunto CVE-2026-48356 al catalogo KEV, l’elenco delle vulnerabilità per le quali esistono prove di sfruttamento attivo. Le agenzie federali civili statunitensi devono applicare le correzioni entro il 10 novembre 2026; la CISA invita tutte le organizzazioni a dare priorità alle vulnerabilità del catalogo.

3. Esiste una correzione?

Sì. Adobe ha corretto la falla il 14 luglio 2026 con il bollettino APSB26-73. Le versioni corrette sono le release contrassegnate “2026-jul” e, per Adobe Commerce Events, la 1.21.0. Per questa falla Adobe indica come interessata anche la versione 2.4.9: chi la usa deve quindi installare la release 2.4.9-2026-jul.

4. Basta installare l’aggiornamento?

No, se il negozio non era aggiornato in tempo. La patch impedisce nuovi attacchi attraverso questa falla, ma non rimuove ciò che fosse già stato caricato: secondo Sansec i file caricati restano sul server anche quando non possono essere eseguiti.

5. Che cosa va fatto controllare all’agenzia o all’hosting?

La versione esatta in uso e la presenza dell’aggiornamento APSB26-73; la cartella dei caricamenti pub/media/custom_options/ e l’eventuale backdoor accesson.php; i blocchi e le pagine CMS, gli account di amministrazione sconosciuti e i processi insoliti sul server. Secondo Sansec, la data dell’ultima modifica dei blocchi interessati indica anche l’ultimo intervento dell’attaccante. Se si trova qualcosa, Sansec consiglia di cambiare dopo la pulizia le password del database, dell’amministrazione e delle integrazioni API.

Fonti citate

Immagine di copertina generata con IA.