HTTP2Shell non è un bug di HTTP/2, ed è questo a far paura

Il tuo team ha probabilmente un elenco dei framework da cui dipende. Ne ha uno dei decompressori? HTTP2Shell è uno dei nomi ora associati a una falla di esecuzione di codice da remoto che colpisce Node.js e, secondo le segnalazioni, alcune librerie Python. Nonostante il nome, il protocollo non c'entra. Il colpevole è un decoder di compressione.

Il bug sta nel decompressore, non nel protocollo

Come spiega Brandefense, si tratta di un'unica falla, la CVE-2026-111497, nel decoder Brotli incluso in Node.js. All'inizio si chiamava Node2Shell e, dalla tarda serata del 23 ottobre (UTC), anche HTTP2Shell. Node.js l'ha corretta il 21 ottobre 2026 nelle versioni 22.23.4, 24.22.1 e 26.12.1. Il record CVE le assegna 9,2 su CVSS 4.0. L'avviso attribuisce la segnalazione a OpenAI Codex Security.

Secondo Aikido, la stessa falla di Brotli riguarda molte librerie e applicazioni che usano HTTP con Brotli o brotlicffi installato. L'esecuzione di codice da remoto sull'immagine ufficiale di Node.js 24.22.0 è, per ora, ciò che hanno riferito i ricercatori. Aikido la presenta come una segnalazione e non come un test proprio, e aggiunge che l'exploit non funzionava ogni volta. Il codice proof-of-concept pubblico, stando alle segnalazioni, manda in crash Node.js non aggiornato, ma una RCE funzionante non è stata mostrata in codice pubblico. A nostro avviso, questa distinzione cambia con quanta enfasi descrivere la falla. Non cambia la rapidità con cui aggiornare.

Il nome sbagliato indica il livello sbagliato

Chiamarla HTTP2Shell è comprensibile. La falla emerge sul percorso HTTP e il nome è orecchiabile. Ma porta l'attenzione sul livello sbagliato. Nessuno dovrebbe mettersi a cercare un'impostazione di HTTP/2 da disattivare.

L'analisi di Brandefense, che riprende la spiegazione di Vercel, mostra quanto sia ordinaria l'esposizione. Node.js non decodifica Brotli da solo. Un'app è esposta quando il suo codice, o una libreria che usa, decomprime dati Brotli controllati da un attaccante. Il ricercatore Ron Masas ha scritto su X che, su un runtime vulnerabile, «app.use(express.json) basta». Brandefense dice che coincide con quanto fa il codice sorgente di Express 5. Una richiesta JSON con codifica del contenuto Brotli viene decodificata prima che giri il codice delle tue route.

È questa la parte scomoda. In molti team, sospettiamo, nessuno ha scritto una funzione Brotli e nessuno ne ha rivista una. L'esposizione è arrivata come comportamento predefinito di qualcosa che hai scelto. E Brandefense nota che anche altri middleware, framework, reverse proxy e il tuo codice possono decodificare Brotli. Ognuno è un posto da controllare.

Aggiornare deve diventare lavoro di infrastruttura, non un ticket dello sprint

La cronologia è l'argomento. Node.js ha rilasciato le correzioni alle 10:38 UTC del 21 ottobre. Secondo Brandefense, il primo repository GitHub per la CVE è comparso circa cinque ore dopo, e a tarda sera del 23 ottobre una ricerca ne restituiva 25. A nostro avviso, chi difende non ha tregua quando le patch possono essere confrontate con il vecchio codice.

Lo stesso giorno PHP ha rilasciato le proprie correzioni per le falle distinte di PHP2Shell. Il team di sicurezza dell'Università di Toronto avverte che ci si aspetta presto uno sfruttamento di massa e che Cloudflare aveva già segnalato i primi attacchi. Non vogliamo fondere due bug senza relazione in un'unica storia. Ma due falle critiche di runtime che arrivano insieme sono l'aspetto di una brutta settimana quando tanto gira su una manciata di runtime condivisi.

C'è una seconda lezione, sul software a fine vita. Brandefense cita Vercel, secondo cui Node.js 20 «non riceverà questa correzione». I team fermi su un runtime non più supportato non hanno una patch di ritardo. Non hanno nessuna patch da applicare. È una decisione di budget presa mesi fa che arriva a scadenza in un weekend.

Wiz sostiene, nella sua analisi di PHP2Shell, che i modelli di IA di frontiera le hanno permesso di sviluppare e adattare exploit funzionanti in poche ore. La tratteremmo come un'affermazione da prendere sul serio, non come un fatto assodato. Se regge, si indebolisce il vecchio conforto che una falla sia troppo complessa perché qualcuno la sfrutti.

Il lavoro di lunedì: inventario, aggiornamento, un responsabile

La nostra raccomandazione è semplice. Controlla le versioni con node --version e individua ogni punto in cui il tuo codice o una dipendenza decomprime Brotli proveniente dall'esterno. Passa alle versioni corrette e abbandona Node.js 20. Non eseguire codice proof-of-concept da GitHub fuori da un laboratorio isolato, perché il codice di exploit di account sconosciuti può nascondere malware.

Il cambiamento più grande è organizzativo. Gli aggiornamenti di runtime e librerie non dovrebbero restare in coda nel backlog dietro al lavoro sulle funzionalità. Devono avere un responsabile, un inventario e una scadenza nella stessa settimana. Una falla come questa non sarà l'ultima, e pensiamo che i team che la tratteranno come ordinaria manutenzione dell'infrastruttura saranno quelli che si accorgeranno appena della prossima.