Brotli è uno di quei componenti che lavorano senza farsi notare: comprime dati per ridurre il traffico e accelerare il trasferimento di contenuti. Proprio per questo una vulnerabilità nel suo decoder può interessare programmi molto diversi, dai servizi web alle applicazioni che scaricano risposte da Internet. La falla identificata come CVE-2026-111497 riguarda la fase in cui i dati vengono decompressi e, in determinate condizioni, può arrivare a compromettere la memoria del processo.
Le correzioni sono state pubblicate, ma il nome Brotli da solo non dice se un sistema sia esposto. La domanda decisiva è un'altra: quel programma sta decomprimendo contenuti che un soggetto esterno può controllare? È da qui che conviene partire, invece di considerare vulnerabile qualsiasi server che utilizzi la compressione.
Il problema è nel decoder, non nel file compresso in sé
Nel bollettino di sicurezza del 21 ottobre, il progetto Node.js descrive un errore nella gestione di un flusso Brotli malformato. In una particolare condizione il decoder interpreta un dato non valido come una richiesta temporanea di ulteriori byte, anziché fermarsi con un errore definitivo. Continuando a elaborare l'input, può scrivere oltre i limiti di un piccolo buffer interno.
Si tratta di una scrittura fuori dai limiti della memoria, non di un semplice difetto che produce una pagina incompleta. A seconda del programma e delle condizioni, le conseguenze potenziali comprendono arresto del processo, esposizione di contenuti in memoria ed esecuzione di codice. Quest'ultimo scenario è grave, ma non equivale a dire che ogni installazione interessata sia automaticamente attaccabile da Internet.
La vulnerabilità riguarda il decoder: comprimere dati con Brotli, senza mai decomprimere input non affidabili, non costituisce di per sé lo stesso percorso di esposizione. Anche un'applicazione che incorpora la libreria potrebbe non utilizzare la funzionalità vulnerabile in un punto raggiungibile da terzi.
Quando un dato esterno diventa un rischio
Per capire il problema basta immaginare un'applicazione che riceve una risposta HTTP compressa da un servizio remoto. Se quella risposta viene passata a un decoder vulnerabile, il contenuto non è più soltanto una sequenza di byte da leggere: viene elaborato da codice nativo che deve gestire correttamente anche dati deliberatamente malformati.
L'avviso di Bun è particolarmente chiaro. Il runtime può decomprimere automaticamente risposte con intestazione Content-Encoding: br durante una chiamata fetch; espone inoltre API di decompressione tramite node:zlib e DecompressionStream. Un server remoto malevolo, oppure un soggetto in grado di alterare una comunicazione non cifrata, può quindi costituire una fonte di input ostile per un'applicazione che utilizza questi percorsi.
Nel caso di Node.js il bollettino ufficiale richiama specificamente i dati Brotli elaborati con node:zlib. Per Envoy, invece, l'avviso del progetto limita il problema ai deployment in cui è configurato il decompressor Brotli. Sono differenze importanti: il nome del componente presente nell'inventario software è un punto di partenza, non una prova che esista un percorso di attacco.
Il rischio merita attenzione soprattutto dove un servizio elabora upload, richieste, risposte o altri flussi compressi provenienti da sistemi non completamente fidati. Una verifica sensata deve ricostruire questo percorso, non limitarsi a cercare la parola Brotli in una lista di dipendenze.
Le versioni corrette, senza confondere i prodotti
Node.js ha distribuito aggiornamenti di sicurezza per i rami 22, 24 e 26. Le versioni da prendere come riferimento sono rispettivamente 22.23.4, 24.22.1 e 26.12.1. Il controllo iniziale è semplice: eseguire node -v nell'ambiente effettivamente usato dall'applicazione, non soltanto sul computer dello sviluppatore.
Bun indica come interessate le versioni dalla 1.0.21 fino a quelle precedenti la 1.4.4. L'aggiornamento alla 1.4.4 incorpora Brotli 1.2.1, che contiene la correzione. Anche qui occorre verificare il runtime che esegue realmente il servizio. Se un'applicazione è stata distribuita come eseguibile autonomo tramite bun build --compile, l'avviso ufficiale richiede di ricompilarla con la versione aggiornata: sostituire Bun sul sistema non cambia il codice già incorporato nel binario.
Per Envoy l'advisory elenca come versioni corrette 1.40.0, 1.39.3, 1.38.6, 1.37.8 e 1.36.12. La presenza del decompressor Brotli nella configurazione resta la condizione da controllare. Chi usa un proxy gestito o un servizio cloud deve chiedere al fornitore quale build sia in esercizio e se il componente sia abilitato.
Il progetto Brotli ha pubblicato la release 1.2.1 il 21 ottobre. Non bisogna però dedurre che aggiornare una libreria di sistema aggiorni automaticamente ogni applicazione: alcuni prodotti distribuiscono copie proprie del decoder.
Il dettaglio che rende difficile la manutenzione
Secondo quanto riportato da Reuters, la causa del problema era stata corretta nel codice sorgente di Brotli già a febbraio, prima che ne venisse riconosciuta la rilevanza per la sicurezza. Non era però stata pubblicata una nuova release che portasse quella modifica agli utilizzatori. La vulnerabilità è emersa durante test di sicurezza condotti da OpenAI ed è stata poi divulgata pubblicamente.
La vicenda mostra una distinzione spesso trascurata: un fix presente nel codice non equivale a una correzione installata nei prodotti. Tra la modifica iniziale, una release ufficiale, l'aggiornamento delle dipendenze e il rilascio in produzione possono esserci più passaggi indipendenti. Ognuno può lasciare in circolazione una copia vulnerabile.
È anche il motivo per cui un inventario basato soltanto sui pacchetti dichiarati dal progetto non sempre basta. Un container può utilizzare un'immagine precedente; un programma compilato può includere una versione statica; un servizio gestito può adottare tempi di aggiornamento diversi. Prima di dichiarare conclusa la manutenzione occorre verificare l'artefatto effettivamente distribuito.
Una checklist utile, senza allarmismi
Il primo passo è identificare i servizi che utilizzano Node.js, Bun o Envoy e confrontare le versioni realmente in esecuzione con i rispettivi bollettini. Poi bisogna cercare i punti in cui vengono decompressi dati Brotli provenienti da client, server esterni o file caricati dagli utenti. Se l'applicazione non percorre mai quelle funzioni, la priorità pratica può essere diversa da quella di un endpoint che le usa con input arbitrario.
Il secondo passo è aggiornare il runtime o il prodotto, ricostruire eventuali immagini container ed eseguibili incorporati e distribuire nuovamente gli artefatti. Il terzo è verificare che i processi riavviati stiano effettivamente usando la build corretta. Una dipendenza aggiornata nel repository di sviluppo non protegge un servizio rimasto in esecuzione con il vecchio binario.
Se l'aggiornamento non è immediato, la mitigazione temporanea consiste nell'evitare la decompressione Brotli di input non affidabili nei percorsi interessati, dopo aver valutato l'impatto funzionale. Bun documenta, per esempio, un'opzione per disattivare la decompressione in una specifica chiamata fetch; non è una soluzione generale per tutte le API. Le mitigazioni vanno quindi scelte per prodotto e configurazione, non copiate indistintamente.
Infine, serve una comunicazione proporzionata. I bollettini documentano la possibilità di conseguenze gravi, non dimostrano che ogni applicazione sia sfruttabile né che ogni server sia già stato compromesso. Il risultato utile per chi gestisce software è più concreto di uno slogan sulla vulnerabilità del momento: sapere dove avviene la decompressione, quali versioni sono distribuite e quale aggiornamento ha raggiunto davvero la produzione.