CISA ha inserito nel catalogo delle vulnerabilità sfruttate attivamente due falle gravi che toccano da vicino chi vende online o gestisce applicazioni web: una in Adobe Commerce/Magento e una nella libreria Google Brotli. Per un’azienda, il punto non è solo tecnico: significa rischio reale di compromissione del sito, interruzione del servizio, furto di dati e uso dell’infrastruttura per distribuire codice malevolo.
Se la tua azienda usa Magento, Adobe Commerce o applicazioni basate su Node.js che trattano contenuti compressi Brotli, la notizia ti riguarda adesso. Il fatto che CISA abbia classificato entrambe le vulnerabilità come già sfruttate in attacchi reali cambia la priorità: non si parla più di prevenzione teorica, ma di riduzione urgente del rischio.
Cosa è successo
Il 28 ottobre 2026 The Hacker News ha riportato che la U.S. Cybersecurity and Infrastructure Security Agency ha aggiunto due vulnerabilità al proprio catalogo KEV, cioè l’elenco delle falle per cui esistono prove di sfruttamento attivo.
Le due vulnerabilità segnalate sono:
- CVE-2026-48356 in Adobe Commerce e Magento, con punteggio CVSS 9.3
- CVE-2026-111497 nella libreria Google Brotli, con punteggio CVSS 9.2
L’inserimento nel KEV è un segnale importante perché indica che gli attaccanti non stanno aspettando: stanno già tentando di usare queste debolezze contro sistemi reali. Per le agenzie federali civili statunitensi, la scadenza fissata da CISA per applicare le correzioni è il 10 novembre 2026, un ulteriore indicatore dell’urgenza.
Il caso più concreto per chi vende online: PolyShell su Adobe Commerce e Magento
La vulnerabilità CVE-2026-48356, soprannominata PolyShell, riguarda un problema di caricamento non sicuro di file pericolosi. In pratica, un attaccante può arrivare all’esecuzione di codice arbitrario nel contesto dell’utente corrente, con la possibilità di ottenere accesso elevato o controllo su account e sessioni.
Secondo quanto riportato, la società di sicurezza Sansec ha osservato attacchi che sfruttano questa falla per compromettere centinaia di negozi e-commerce. Il meccanismo visto in questi incidenti prevede l’iniezione di un loader malevolo all’interno di un blocco CMS di Magento. Quel loader, a sua volta, è pensato per scaricare ed eseguire un payload controllato dagli attaccanti.
Un aspetto importante è che, almeno finora, non sarebbe stato recuperato il malware di fase successiva. Questo rende più difficile capire l’obiettivo finale delle campagne: furto di dati di pagamento, accesso persistente al backend, alterazione dei contenuti del sito, skimming lato client o preparazione di ulteriori compromissioni.
C’è però un dato che basta da solo a far salire l’attenzione: l’attività sarebbe in corso almeno da luglio 2025. Non si tratta quindi di una finestra di attacco appena aperta, ma di una superficie probabilmente già battuta da tempo.
La seconda minaccia: Brotli e il rischio per servizi web e cloud
La vulnerabilità CVE-2026-111497 colpisce la libreria Google Brotli, molto diffusa in numerosi progetti e prodotti software. Il problema è descritto come una gestione non corretta di un valore di ritorno nel decoder, che può consentire a un attaccante remoto non autenticato di corrompere la memoria del processo, leggere contenuti sensibili, causare un crash o, in alcuni casi, arrivare all’esecuzione di codice arbitrario tramite uno stream Brotli appositamente costruito.
Questa falla è stata indicata anche con i nomi Broccoli2Shell, HTTP2Shell e Node2Shell. Il punto critico, per le aziende, è che il rischio non riguarda solo chi sviluppa software: molte applicazioni moderne, servizi web, API, reverse proxy e componenti cloud usano Brotli direttamente o indirettamente.
I dati citati nell’articolo mostrano che esistono già tentativi di sfruttamento osservati sul campo. Previdian ha registrato almeno un tentativo contro i propri sensori al 27 ottobre 2026 da un IP statunitense. ELLIO ha inoltre dichiarato di aver rilevato traffico di exploit reale, associato a un IP geolocalizzato nei Paesi Bassi, e di aver confermato che l’exploit pubblico è in grado di ottenere una shell su build vulnerabili.
Non significa che ogni server Node.js sia automaticamente esposto. Come ricordato dagli analisti citati, l’esposizione dipende dal fatto che l’applicazione passi al decoder Brotli dati compressi controllabili dall’attaccante. Tuttavia, il perimetro potenziale è molto ampio.
Perché questa vulnerabilità Brotli merita attenzione anche se non usi Magento
Qui c’è l’aspetto che molte PMI rischiano di sottovalutare: Brotli non è un prodotto di nicchia. È una libreria open source ampiamente adottata e presente, direttamente o indirettamente, in diversi stack applicativi.
L’articolo cita la distribuzione di patch o verifiche di impatto da parte di molti fornitori e progetti, tra cui PHP, Node.js, Bun, Envoy Proxy, Istio, .NET, Python, ClickHouse e altri. Questo allarga il problema oltre il perimetro dell’e-commerce puro.
Per Node.js, le versioni corrette riportate sono:
- 22.23.4
- 24.22.1
- 26.12.1
Il messaggio è chiaro: per Node.js non sarebbe disponibile un workaround completo, quindi aggiornare è l’unica mitigazione efficace. Chi usa linee di rilascio non più supportate dovrebbe pianificare il passaggio a versioni attive.
Anche PHP ha rilasciato aggiornamenti nelle versioni 8.5.12-1, 8.4.27-1, 8.3.36-1 e 8.2.35-1. Questo è rilevante per molte aziende italiane, perché PHP rimane largamente usato in siti aziendali, portali e integrazioni web.
Il rischio operativo per un’impresa
Quando si parla di esecuzione di codice remoto o di compromissione di un e-commerce, il rischio non è solo “il sito che va giù”. Le conseguenze possibili per un’azienda includono:
- blocco delle vendite online
- modifica non autorizzata di pagine, contenuti o prezzi
- inserimento di codice per rubare dati dei clienti
- furto di credenziali amministrative o di sessioni
- utilizzo del server compromesso per attacchi successivi
- danni reputazionali e contestazioni da parte dei clienti
- possibili implicazioni di conformità se vengono coinvolti dati personali
Per questo il tema non riguarda solo l’IT interno o il fornitore del sito: coinvolge direttamente direzione, operations, amministrazione e chi gestisce il rapporto con i clienti.
Cosa significa per la tua azienda
Se la tua azienda ha un e-commerce, un portale clienti o applicazioni web esposte su Internet, questo è il momento di fare una verifica rapida ma strutturata.
1. Capisci subito se sei coinvolto
Verifica se usi Adobe Commerce o Magento, direttamente o tramite agenzia/web provider. In parallelo, chiedi ai fornitori applicativi se nei vostri ambienti ci sono componenti Node.js, PHP o altri software che incorporano Brotli.
2. Applica gli aggiornamenti con priorità alta
Se la piattaforma è vulnerabile, la patch va pianificata come attività urgente. Nel caso di Node.js, le versioni corrette indicate sono precise e l’aggiornamento è la misura principale.
3. Controlla i segnali di compromissione
Per Magento e Adobe Commerce, è opportuno verificare i blocchi CMS, i file caricati di recente, le modifiche anomale al codice e gli accessi amministrativi. Se il sito mostra comportamenti insoliti, redirect, rallentamenti o modifiche non spiegate, non limitarti ad aggiornare: prima serve anche un controllo forense minimo.
4. Rivedi backup e ripristino
In situazioni come questa, il backup non è un dettaglio ma la rete di sicurezza operativa. Assicurati che esistano copie recenti, integre e testate dei contenuti del sito, del database e della configurazione. Se vuoi ridurre il rischio di fermo prolungato, vale la pena strutturare una soluzione di remote backup adatta ai sistemi critici.
5. Riduci la dipendenza dall’intervento “a chiamata”
Le vulnerabilità ad alta priorità richiedono tempi stretti, coordinamento con fornitori e verifica post-intervento. Per molte PMI il vero problema non è la patch in sé, ma accorgersi tardi dell’urgenza. Un supporto continuativo di assistenza informatica aiuta a trasformare le emergenze in attività governate.
6. Considera il tema dati personali
Se un e-commerce o un portale clienti viene compromesso, il problema può toccare anche dati personali e credenziali. In quel caso serve valutare rapidamente gli obblighi organizzativi e documentali, anche lato GDPR.
Non basta “aggiornare appena possibile”
Una delle lezioni più importanti di questa vicenda è che la semplice disponibilità di una patch non equivale alla messa in sicurezza. Nella pratica aziendale servono almeno tre passaggi:
- identificare i sistemi realmente esposti
- verificare se ci sono già tracce di abuso
- aggiornare senza interrompere processi critici più del necessario
Questo vale soprattutto quando il software vulnerabile è inserito in catene più complesse: e-commerce con plugin, server gestiti da terzi, applicazioni sviluppate su misura o servizi cloud con componenti ereditati.
Per molte aziende il rischio maggiore non è il bug isolato, ma la mancanza di visibilità sul proprio inventario IT. E proprio in questi casi gli attacchi “di massa” trovano terreno fertile.
Cosa aspettarsi nelle prossime settimane
L’inserimento nel catalogo KEV tende ad aumentare l’attenzione del mercato e, spesso, anche il numero di tentativi opportunistici. Gli attaccanti sanno che molte organizzazioni impiegano giorni o settimane per capire se sono coinvolte. Questo rende particolarmente delicata la finestra immediatamente successiva alla divulgazione pubblica e alla disponibilità degli exploit.
Per chi gestisce un e-commerce, la priorità è evitare due errori opposti: sottovalutare il problema oppure applicare modifiche in fretta senza controllare se il sistema è già stato toccato. La sequenza corretta è: inventario, verifica dell’esposizione, controllo dei segnali di compromissione, aggiornamento, monitoraggio.
Domande frequenti
Se uso Magento ma il sito sembra funzionare, posso aspettare?
No. Il fatto che il sito appaia operativo non esclude una compromissione silenziosa o un tentativo in corso. Se usi Magento o Adobe Commerce, la verifica va fatta subito.
La vulnerabilità Brotli riguarda tutti i server Node.js?
Non automaticamente. Il rischio dipende dal fatto che l’applicazione decomprima dati Brotli influenzabili da un attaccante. Però, se usi versioni vulnerabili, l’aggiornamento resta prioritario.
Se il mio fornitore gestisce il sito, devo fare qualcosa io?
Sì. Anche con un fornitore esterno, l’azienda resta esposta alle conseguenze operative, economiche e reputazionali. Conviene chiedere conferma scritta di verifica, patch applicate e controlli eseguiti.