Il 27 ottobre 2026 l'agenzia statunitense CISA ha inserito nel suo catalogo delle vulnerabilita' sfruttate attivamente una falla che non porta il nome di un prodotto riconoscibile, ma di una libreria di compressione dati che gira, spesso senza che nessuno se ne accorga, dentro la maggior parte dei siti, delle API e dei gestionali web moderni. Si chiama Brotli, e' stata sviluppata da Google ed e' cosi' diffusa da essere installata di default in Node.js, in molte librerie Python e in .NET. La vulnerabilita', nota come Node2Shell (o Broccoli2Shell), ha un punteggio di gravita' di 9.2 su 10 e un tentativo di sfruttamento reale e' gia' stato osservato il 26 ottobre. Per una PMI con un sito, un e-commerce o un'applicazione web, la domanda da porsi non e' se si usa Brotli, ma chi nella propria filiera di sviluppo lo sa.
Cos'e' Brotli e perche' e' quasi ovunque
Brotli e' un algoritmo di compressione pensato per alleggerire il traffico web: pagine, risposte delle API e risorse statiche vengono compresse prima di viaggiare tra server e browser, per far caricare i siti piu' velocemente. Proprio per questa efficienza e' stato adottato su larghissima scala: e' integrato direttamente nel runtime di Node.js, e' usato da librerie Python molto comuni come requests, httpx e aiohttp (tramite i pacchetti brotli e brotlicffi), e' presente in .NET, nel runtime Bun e in proxy e gateway API come Envoy e Istio, spesso installati davanti a piattaforme di e-commerce o applicazioni a microservizi. Secondo Red Hat, anche Firefox e Thunderbird potrebbero essere coinvolti. Nessuno sceglie di installare Brotli di proposito: arriva incluso nel linguaggio, nel framework o nel server che si sta gia' usando, ed e' proprio questo a renderlo un rischio difficile da vedere.
Chi e' concretamente a rischio
La falla, identificata come CVE-2026-111497, e' un errore di scrittura fuori dai limiti di memoria nel decoder di Brotli: un flusso di dati compresso costruito ad arte puo' corrompere la memoria del processo che lo riceve e, nei casi peggiori, portare all'esecuzione di codice da remoto senza bisogno di credenziali. Non riguarda solo chi scrive codice Node.js in prima persona. Sono potenzialmente esposti:
- Siti, e-commerce e applicazioni costruiti su Node.js (corretto nelle versioni 22.23.4, 24.22.1 e 26.12.1), specialmente se basati su framework come Express o Koa;
- Backend e API in Python che si appoggiano a requests, httpx o aiohttp con supporto Brotli attivo (corretto nella versione 1.2.1 dei pacchetti brotli e brotlicffi);
- Applicazioni .NET e script PowerShell, per cui Microsoft ha rilasciato tra il 25 e il 26 ottobre una patch fuori ciclo per .NET 8, 9 e 10, la release candidate di .NET 11, Visual Studio e PowerShell stesso;
- Servizi collocati dietro un reverse proxy o un API gateway come Envoy o Istio, molto diffusi per smistare il traffico verso microservizi e applicazioni containerizzate;
- Applicazioni basate su Bun (corretto nella versione 1.4.4).
In pratica, un'azienda puo' essere esposta anche senza aver mai scritto una riga di Node.js: basta che il fornitore del sito, dell'e-commerce o del gestionale lo utilizzi nel backend, o che il traffico passi attraverso un proxy vulnerabile.
Perche' conta proprio ora
Node.js ha reso pubblica la falla il 21 ottobre nel suo bollettino di sicurezza, segnalata dal team di sicurezza Codex di OpenAI. Il 27 ottobre CISA l'ha aggiunta al catalogo delle vulnerabilita' sfruttate attivamente (KEV), imponendo alle agenzie federali statunitensi di correggerla entro il 10 novembre: un inserimento che avviene solo quando esistono prove di sfruttamento reale, non teorico. A confermarlo e' la societa' di intelligence sulle minacce ELLIO, che ha documentato una fase di ricognizione gia' a partire dal 13 ottobre, con scansioni mirate a individuare host che decomprimono dati Brotli, seguita il 26 ottobre alle 15:08 UTC dal primo tentativo di sfruttamento reale: un indirizzo IP ha inviato un payload contenente una catena di exploit costruita specificamente per colpire Node.js in versione 24.22.0 su architettura x86-64. Non si tratta quindi di una vulnerabilita' da tenere d'occhio in futuro, ma di un attacco gia' in corso.
Le domande da fare subito al proprio sviluppatore o fornitore IT
Per capire se la propria azienda e' esposta non serve essere tecnici: bastano le domande giuste rivolte a chi gestisce il sito o l'applicazione web. Tra le piu' utili:
- Che versione di Node.js usa il sito o l'applicazione, ed e' stata aggiornata a 22.23.4, 24.22.1 o 26.12.1?
- Se il backend e' in Python, le librerie che usano Brotli (requests, httpx, aiohttp) sono state aggiornate alla versione corretta?
- Se c'e' un'applicazione o un gestionale in .NET, o script in PowerShell, e' stata applicata la patch fuori ciclo rilasciata da Microsoft?
- Il traffico del sito passa attraverso un reverse proxy o un API gateway come Envoy o Istio, ed e' stato aggiornato?
- Chi, concretamente, tiene un elenco aggiornato delle librerie di terze parti usate dal sito o dall'applicazione, e con quale frequenza lo controlla?
Se il proprio fornitore non sa rispondere con precisione a queste domande, e' un segnale che l'inventario delle dipendenze software dell'azienda non e' sotto controllo.
Perche' serve un monitoraggio continuo, non patch sporadiche
Il caso Node2Shell mostra bene un problema che va oltre questa singola falla: il rischio non sta sempre nel prodotto con il nome piu' noto, ma in una libreria di basso livello che si trova tre o quattro passaggi piu' in profondita' nello stack tecnologico, ereditata da un framework, da un runtime o da un proxy che nessuno ricontrolla dopo l'installazione iniziale. Una patch applicata una tantum, dopo l'ultimo allarme, non basta: servono un inventario costante delle componenti software usate da siti e applicazioni, un monitoraggio dei bollettini di sicurezza dei fornitori coinvolti e un piano di aggiornamento che non dipenda dal fatto che la notizia sia arrivata o meno sui giornali. Hi-Keep segue questo aspetto nell'ambito del servizio Siti & Web Application, occupandosi della verifica periodica delle versioni di runtime, framework e librerie usate dai siti e dalle applicazioni web dei propri clienti, cosi' da intercettare un problema come questo prima che diventi un incidente.
Cosa puo' fare Hi-Keep
Se la tua azienda ha un sito, un e-commerce o un'applicazione web e non sai con certezza quale runtime, quali librerie o quale proxy girano dietro le quinte, Hi-Keep puo' effettuare una verifica mirata sulla falla Node2Shell: controllare la versione di Node.js, Python, .NET o dei proxy in uso, applicare gli aggiornamenti necessari e impostare un monitoraggio continuo delle dipendenze software, cosi' da non doversi affidare a un controllo isolato ogni volta che emerge una nuova falla critica.