In questo articolo Indice dei contenuti 3 sezioni
La vulnerabilità Node2Shell, conosciuta anche come HTTP2Shell o Broccoli2Shell, non è più un problema confinato ai test di laboratorio. Negli Stati Uniti la CISA, l’agenzia per la sicurezza informatica e delle infrastrutture, ha inserito la falla nel catalogo Known Exploited Vulnerabilities dopo i primi segnali di tentativi di sfruttamento. Nel frattempo diverse reti di honeypot hanno iniziato a intercettare richieste costruite apposta per colpire le applicazioni che decodificano dati Brotli, l’algoritmo di compressione molto usato sul Web per alleggerire pagine, script e altri contenuti trasferiti in rete.
Il difetto si trova nel decoder della libreria sviluppata da Google, ma può diventare un problema di esecuzione di codice remoto per Node.js e per molti altri software che incorporano lo stesso componente. Il codice difettoso risale addirittura a Brotli 1.0.3, pubblicato a marzo 2018. Una prima correzione è arrivata a fine febbraio 2026, senza però che gli sviluppatori ne riconoscessero le implicazioni di sicurezza e senza una release dedicata. Solo mesi dopo, anche grazie all’analisi dei ricercatori di OpenAI Codex Security, la gravità della questione è diventata evidente.
Versioni coinvolte e primi controlli
Le versioni di Brotli dalla 1.0.3 alla 1.2.0 contengono il codice vulnerabile e Google ha pubblicato le edizioni corrette 1.0.10, 1.1.1 e 1.2.1. La falla coinvolge quindi anche componenti Python e .NET, tanto che Microsoft ha distribuito di domenica un aggiornamento straordinario fuori dal normale calendario. Sul versante Node.js la correzione è arrivata il 21 ottobre 2026 con le versioni 22.23.4, 24.22.1 e 26.12.1. Chi usa una release precedente di uno di questi rami deve aggiornare.
Il primo controllo per capire se si è esposti a Node2Shell è banale e consiste nel chiedere a Node.js la propria versione dal terminale, con un’istruzione identica su Windows, Linux e macOS. Una verifica più completa sfrutta process.version e process.versions.brotli per mostrare insieme la versione del runtime eseguito, quella di Brotli dichiarata e il percorso del file node effettivamente in uso. Quest’ultimo dato è prezioso quando sulla stessa macchina convivono più installazioni. Meglio però non basarsi solo sul numero di Brotli, perché le release di sicurezza hanno integrato la patch direttamente nel codice incluso nel runtime e il riferimento più affidabile resta la versione di Node.js.
Su Windows capita più spesso di quanto si pensi di avere copie sparse tra installer ufficiale, nvm per Windows, programmi di sviluppo, shell compatibili Unix o vecchie cartelle rimaste nel PATH. Il comando where.exe node elenca tutte quelle raggiungibili dal prompt, mentre PowerShell offre un risultato ancora più leggibile. Su Linux e macOS si ricorre invece a which o type.
Perché npm audit non basta
npm audit resta utile per scovare vulnerabilità nelle dipendenze JavaScript dichiarate dal progetto, ma in questo caso il problema risiede nel Brotli nativo incorporato nel runtime. Non serve quindi che nel package.json compaia una dipendenza chiamata “brotli”. Un’applicazione può raggiungere il decoder vulnerabile tramite il modulo node:zlib, per esempio con brotliDecompress(), brotliDecompressSync() o createBrotliDecompress(). Una ricerca nel codice sorgente con grep su Linux e macOS o con gli strumenti di PowerShell aiuta a capire quanto il progetto sia davvero esposto. Una corrispondenza non dimostra che l’applicazione sia sfruttabile, però indica rapidamente i punti da esaminare.
Il pericolo diventa concreto quando un aggressore riesce a far arrivare al decoder dati non attendibili. Gli esempi più interessanti per chi attacca sono un server che accetta richieste compresse in formato br, un servizio che decomprime file caricati dagli utenti o un’applicazione che elabora risposte provenienti da sistemi non fidati. L’exploit segnalato da CISA non è ancora riuscito a ottenere una shell nei test di laboratorio, ma il framework usato coincideva con codice proof of concept pubblico e anche i tentativi falliti potevano mandare in crash il processo.
Aggiornare davvero, container compresi
La strada migliore è installare una versione corretta di Node.js. Per il ramo LTS 24.x la release sicura è la 24.22.1 e chi usa nvm può procedere con nvm install 24.22.1 e nvm use 24.22.1, ripetendo poi il controllo della versione. Dove Node.js arriva dal gestore pacchetti della distribuzione Linux bisogna applicare gli aggiornamenti del distributore. Debian, Ubuntu, Red Hat e altre possono infatti inserire la patch tramite backport mantenendo una numerazione apparentemente più vecchia, per cui conviene consultare il bollettino del vendor e il changelog del pacchetto.
Un caso frequente riguarda Docker, perché aggiornare Node.js sull’host non modifica il runtime contenuto in un’immagine già costruita. Lanciando docker exec con il nome del container e il controllo di versione si scopre cosa gira davvero. Se compare per esempio v24.22.0 occorre aggiornare l’immagine di base nel Dockerfile, ricostruirla e ridistribuire il container, verificando poi di nuovo. Lo stesso vale per le immagini derivate da node:22, node:24 o node:26, dato che un’immagine creata giorni o settimane prima non diventa sicura solo perché il tag remoto punta ora a una release aggiornata.
Quanto al nome Broccoli2Shell, uno dei tre con cui è nota la falla, nasce semplicemente dall’assonanza con “broccoli”, a cui è stato aggiunto il classico suffisso 2Shell che richiama la possibilità di arrivare all’esecuzione di comandi sul sistema vulnerabile.
Fonte: TecnoAndroid