Broccoli2Shell dimostra che il codice più rischioso è quello che non hai scelto

Quale libreria decomprime i dati che arrivano al tuo server? Se non sai rispondere in meno di un minuto, Broccoli2Shell è un problema anche tuo, che tu abbia mai scritto o meno la parola "Brotli" nel tuo codice.

Il bug è il CVE-2026-111497, una scrittura fuori dai limiti nel decoder Brotli di Google. Secondo Strobes, riguarda le versioni di Brotli dalla 1.0.3 alla 1.2.0 e ha un punteggio di 9,2 (critico) su CVSS 4.0. Poiché client e server HTTP decodificano automaticamente Content-Encoding: br, raggiunge Node.js, Python, Bun e altri stack attraverso il normale traffico web. Node.js ha rilasciato le correzioni il 21 ottobre nelle versioni 22.23.4, 24.22.1 e 26.12.1, come riportano Qualys e altri. Il nome è cambiato più volte (Node2Shell, HTTP2Shell, Broccoli2Shell), sempre per lo stesso CVE.

Il cambio di nome è la vera storia

Strobes fa un'osservazione acuta: il soprannome è cambiato tre volte in quattro giorni, e ogni nome rifletteva chi il settore riteneva esposto. È iniziato come una patch per un runtime ed è diventato un problema di dipendenze e di supply chain. Crediamo che questo percorso sia la lezione. Il codice vulnerabile si trova in una libreria C che molti progetti includono, collegano o ereditano. Nessuno l'ha "installata" per scelta. È arrivata con il runtime, il client HTTP o l'immagine.

Per questo si tratta di un'infrastruttura invisibile. Semgrep osserva che il bug non è in un pacchetto npm chiamato brotli, né in body-parser stesso. Eppure body-parser passa al decoder dati compressi controllati dall'attaccante. Il tuo scanner di dipendenze può restare in silenzio mentre il problema sta un livello più sotto. Strobes segnala anche un tracker pubblico, gestito da ricercatori indipendenti, che elenca i progetti le cui copie incluse non erano ancora corrette il 24 ottobre, tra cui il runtime.NET, l'estensione brotli di PHP e la gemma brotli di Ruby. Aggiornare la distribuzione non serve a nulla per il software che porta con sé una copia privata.

L'esposizione dipende dai percorsi, e il peggiore è quello in uscita

Non tutti i servizi Node sono ugualmente a rischio, ed è bene dirlo chiaramente per evitare il panico. Semgrep sottolinea che l'applicazione deve eseguire una versione interessata, usare un parser compatibile con Brotli, avere la decompressione attiva ed esporre una route in cui è montato. Secondo Strobes, Express 5 con body-parser 2.x decodifica per impostazione predefinita i corpi delle richieste Brotli, quindi un singolo app.use(express.json) può mettere il decoder davanti a traffico anonimo.

Il percorso che troviamo più scomodo è quello che nessuno monitora: le risposte che il tuo stesso codice scarica. Il fetch integrato di Node decodifica Brotli in automatico, e Strobes dice che urllib3, aiohttp e httpx di Python fanno lo stesso quando è installato un pacchetto Brotli, anche se il tuo codice non lo importa mai. Webhook, anteprime dei link, "importa da URL", crawler e agenti IA che navigano sono tutte porte da cui può entrare un estraneo. Strobes aggiunge che nessun WAF vedrà questo percorso. Il WAF di Vercel, secondo TuxCare, blocca la route in ingresso ma non le risposte recuperate altrove.

Le patch eroiche non scalano; gli inventari sì

La reazione tipica è un weekend di aggiornamenti frenetici. Per Node 22, 24 e 26 funziona: la correzione è, parole di TuxCare, noiosa. Ma TuxCare avverte anche che Node.js 20, 18 e precedenti non ricevono nulla dal progetto originale, e il parco dimenticato è proprio quello che morde. Poi c'è la trappola del riavvio: un processo in esecuzione mantiene in memoria il vecchio decoder.

Anche la cronologia dovrebbe preoccuparci. TuxCare, citando The Hacker News, dice che la modifica correttiva è entrata nel codice sorgente di Brotli a febbraio 2026 ma non è arrivata in una release di sicurezza fino al 21 ottobre. Strobes aggiunge che nessuno l'aveva collegata all'esecuzione di codice remoto fino a ottobre. Una patch pubblica è una mappa, come ha scritto un autore su Medium. Strobes riferisce che esistono proof of concept pubblici, e secondo TuxCare al 22 ottobre non risultava alcuno sfruttamento in the wild. Considereremmo questa calma temporanea, non rassicurante.

Nella stessa settimana è arrivato PHP2Shell, che Semgrep descrive come una falla presente in PHP da oltre un decennio, e Google Cloud afferma che le applicazioni con PHP 7.4 restano vulnerabili. Due divulgazioni su runtime a un giorno di distanza non dimostrano che la sicurezza sia crollata; la stessa Semgrep dice che la tendenza più ampia si sta formando da anni. Ma mostrano quanto poco tempo abbiamo per capire cosa eseguiamo.

Il nostro verdetto

Aggiorna subito, ovviamente. Poi fai il lavoro noioso che ti protegge davvero: tieni un inventario che scenda sotto i manifest dei pacchetti e copra runtime, librerie native incluse, immagini base dei container, runner CI e ogni punto in cui il tuo codice scarica un URL controllato da altri. Dismetti i runtime a fine vita invece di sperare. Ci aspettiamo che prima o poi arrivi il prossimo bug di decompressione, e il team che sa rispondere in pochi minuti a "dove lo eseguiamo?" batterà quello con le migliori imprese di patching.