Vai al contenuto principale
Questione emergente

Cacciare o essere cacciati: l’incidente che svela il segreto del HTTP2Shell

Scoprite come Tanium abbia trasformato un bug nascosto all’interno di un altro software in una soluzione applicabile all’intera flotta, in un’operazione di ricerca Tanium Atlas collaudata e in linee guida per il rilevamento verificate in laboratorio, il tutto entro un giorno dall’ampliamento della portata della vulnerabilità.

Cosa è successo

Node.js ha rilasciato una correzione per il bug CVE-2026-111497 21 ottobre 2026su , classificandolo come “Alto”: dati Brotli appositamente manipolati potrebbero scrivere oltre i limiti di un piccolo buffer all’interno del decodificatore e danneggiare la memoria del processo (Node.js (si apre in una nuova scheda)). Nel giro di un giorno, Imperva ha dimostrato la possibilità di eseguire codice su una build ufficiale di Node.js e l’ha denominata “Node2Shell” (Imperva (si apre in una nuova scheda)). A quel punto il cannocchiale si è rotto. Il bug è presente nella stessa libreria Brotli Googledi , nelle versioni dalla 1,0,3 alla 1,2,0, e Aikido ha dimostrato che i comuni client HTTP per Python la caricano automaticamente (Aikido (si apre in una nuova scheda)). Il nome è diventato HTTP2Shell.

MinacciaSquadra di interventoRisultato
HTTP2Shell (CVE-2026-111497): scrittura fuori dai limiti nel decodificatore Brotli integrato in Node.js, nei pacchetti Brotli per Python, in Bun, Envoy e in altri software; CVSS 4,0 9,2; prove di concetto rese pubbliche; nessun caso confermato di sfruttamento in ambiente reale alla data di 24 ottobreHuntIQ Threat Hunters + Tanium Guardian + Tanium Atlas + Tanium Threat ResponseGuida pubblica alla ricerca e alla correzione con un prompt Atlas verificato circa 21 ore dopo la ridefinizione dell’ambito; l’exploit è stato riprodotto in laboratorio e la sua impronta endpoint è stata mappata in un’attività di ricerca comportamentale

GoogleIl record CVE ottiene un punteggio di 9,2 secondo il CVSS 4,0 (record CVE (si apre in una nuova scheda)) e, alla data di 24 ottobre , non era stato confermato alcun caso di sfruttamento in ambiente reale (Strobes (si apre in una nuova scheda)). Ciò ha lasciato un exploit pubblico, una correzione e nessuna visione chiara di dove venga eseguito il codice vulnerabile.

Come è andato il primo giorno

Tanium Il Guardian ha ridefinito la propria risposta incentrandola sul nome più ampio “ HTTP2Shell ” in tarda serata 23 ottobre (ora degli Stati Uniti) e ha istituito una sala operativa nella stessa ora. Le squadre sul campo hanno ricevuto una comunicazione interna nel giro di un’ora e, nel corso di un’operazione di ricerca condotta durante la notte, sono stati raccolti tutti i prodotti noti per includere il decodificatore, insieme alle versioni corrette e alle versioni con trappole.

Entro la mattina seguente, i ricercatori di HuntIQ avevano allestito due server Node.js appositamente resi vulnerabili in un laboratorio isolato, uno all’interno di un container e l’altro installato direttamente sull’host, e avevano lanciato un proof of concept pubblico contro entrambi. Per quanto riguarda il container, l’exploit è riuscito a eseguire il codice nella maggior parte dei tentativi, ciascuno dei quali solo dopo una serie di tentativi falliti. Rispetto all'installazione sul server della stessa versione di Node.js, ha sempre e solo causato il crash del servizio.

La prima lezione riguardava il punto in cui compare il codice dell'autore dell'attacco. L'exploit non ha provocato l'avvio di una shell da parte di Node.js. Ha sostituito completamente il processo Node.js, pertanto un’operazione di monitoraggio che attenda il messaggio “node ha avviato una shell” non rileverebbe nulla. La seconda lezione è stata ancora più evidente: ogni tentativo fallito blocca il servizio, e il riavvio che lo ripristina è proprio ciò che consente all’autore dell’attacco di riprovare. Sul container di laboratorio, il runtime si è riavviato ripetutamente nel giro di pochi minuti. Tale andamento è visibile fino a Tanium Threat Response molto tempo dopo il fatto.

I ricercatori hanno integrato entrambe le scoperte nel lavoro già in corso. Il prompt di Atlas è stato testato ripetutamente sugli host di laboratorio compromessi fino a quando non ha individuato in modo affidabile un runtime Node.js all’interno di un container e una copia non inclusa nel pacchetto nella directory /opt, le due posizioni in cui un inventario dei pacchetti non effettua mai la ricerca. Su 22:40 UTC on 24 ottobre, circa 21 ore dopo la ridefinizione dell’ambito, Tanium ha pubblicato l’articolo “HTTP2Shell: Individuare e correggere le copie vulnerabili di Brotli con Tanium”, con quel prompt, le domande manuali che ne stavano alla base e una ricerca del modello “arresto anomalo e riavvio”.

Perché trovare Brotli è stata la parte più difficile

Brotli non compare quasi mai in un inventario del software, poiché è integrato in altri componenti: runtime dei linguaggi di programmazione, ambienti Python, applicazioni desktop, proxy e immagini di container. Una versione patchata di Node.js continua addirittura a segnalare il proprio vecchio numero di versione di Brotli, pertanto la verifica più ovvia fornisce un risultato errato. Ogni copia viene aggiornata da chi ne è il proprietario; ciò significa che la prima domanda da porsi non è «abbiamo installato la patch?», bensì «chi è il proprietario di ogni singola copia?».

Tanium può inserire tutte quelle copie in un unico elenco. L'inventario dei pacchetti riporta ciò che è stato installato, l'albero di origine dei processi indica ciò che è in esecuzione nei container e Tanium SBOM analizza il contenuto delle applicazioni e dei livelli delle immagini: la libreria Brotli inclusa in un'applicazione, il servizio Express 5 che decodifica per impostazione predefinita i corpi delle richieste Brotli, il vecchio decodificatore integrato in un'immagine che la patch dell'host non modifica mai. Ciò che HuntIQ ha apportato è stata una conoscenza diretta dell’attacco. I “cacciatori” ne avevano osservato il malfunzionamento e i tentativi di ripristino, pertanto i clienti sapevano su quali host applicare le patch per primi e a cosa prestare attenzione su quelli su cui non era possibile intervenire.