Le applicazioni che usano Bun >= 1.0.21, < 1.4.4 sono interessate da una vulnerabilità di scrittura in memoria nel decoder Brotli di Google incluso nel runtime. La soluzione di Bun è installare 1.4.4 e ricompilare gli eseguibili prodotti con bun build --compile: questi binari contengono un proprio runtime, quindi aggiornare soltanto la versione di Bun installata non li ripara.
La falla, CVE-2026-111497, ha anche attirato tentativi di sfruttamento segnalati. Nel rapporto del 28 ottobre di Security Affairs, Previdian aveva registrato un tentativo entro il 27 ottobre, e i ricercatori di ELLIO avevano osservato traffico contenente un exploit pubblico capace di eseguire codice sui sistemi vulnerabili. L'entità di questa attività resta incerta, e le osservazioni non dimostrano che gli attaccanti abbiano sfruttato con successo Bun.
Quando Bun raggiunge il decoder vulnerabile
Il bollettino di Bun, pubblicato il 23 ottobre, descrive una scrittura fuori dai limiti nella libreria Brotli: decodificando dati compressi controllati dall'attaccante si possono causare scritture al di fuori del buffer di memoria previsto. Il bollettino elenca come interessate le versioni di Brotli da 1.0.3 a 1.2.0, con due eccezioni: le versioni corrette 1.0.10 e 1.1.1. Bun 1.4.3 contiene Brotli 1.2.0; Bun 1.4.4 passa alla versione corretta 1.2.1.
Un'applicazione non ha bisogno di offrire un servizio di decompressione di dati ostili per raggiungere la libreria. Il fetch di Bun invia per impostazione predefinita Accept-Encoding: gzip, deflate, br, zstd e poi decodifica automaticamente le risposte con Content-Encoding: br. Un server malevolo contattato dall'applicazione può fornire in questo modo dati al decoder. Anche un soggetto posizionato lungo il percorso di rete può farlo, quando la connessione non è cifrata.
Le applicazioni possono raggiungere lo stesso decoder tramite node:zlib, inclusi brotliDecompress, brotliDecompressSync e createBrotliDecompress, oppure tramite DecompressionStream con il formato brotli. Il presupposto è che dati Brotli forniti dall'attaccante raggiungano un'interfaccia interessata.
Bun attribuisce al progetto Brotli la valutazione di esecuzione remota di codice. I manutentori del progetto dicono di non aver testato un attacco contro Bun e di non poter stabilire se l'impatto coincida con quello di altri software. Consigliano comunque di trattare la vulnerabilità come un rischio di esecuzione remota di codice. Il bollettino la classifica come High; tale valutazione di gravità è distinta dalla prova di sfruttamento.
Per le installazioni in attesa di aggiornamento, Bun descrive misure limitate piuttosto che una soluzione alternativa valida per l'intero processo. Su una specifica richiesta fetch, decompress: false sopprime Accept-Encoding: br e disattiva la decompressione delle risposte. Le altre chiamate non sono interessate da questa impostazione. Il bollettino invita inoltre le applicazioni a tenere i dati non attendibili lontani dalle interfacce Brotli di node:zlib e DecompressionStream. Con il decoder aggiornato, i dati non validi producono BROTLI_DECODER_ERROR_FORMAT_BLOCK_SWITCH.
Il rapporto sul catalogo federale richiede precisazioni
Security Affairs riferisce anche che la CISA aveva aggiunto CVE-2026-111497 e CVE-2026-48356, una vulnerabilità di caricamento di file senza restrizioni in Adobe Commerce e Magento nota come PolyShell, al proprio catalogo delle Known Exploited Vulnerabilities. Indica il 29 ottobre 2026 come scadenza federale per la correzione.
L'avviso della CISA del 26 ottobre annuncia voci diverse: CVE-2026-109618, relativa a una corruzione di memoria in PHP, e CVE-2026-109619, relativa allo stato interno obsoleto delle richieste PHP. Quell'annuncio non conferma né le aggiunte di Brotli e Adobe segnalate né la scadenza del 29 ottobre. La CISA cita la Binding Operational Directive 26-04, che si applica alle agenzie del Federal Civilian Executive Branch, e invita le altre organizzazioni a dare priorità alla correzione in base al rischio.
Per PolyShell, Security Affairs riporta il rilevamento di Sansec secondo cui gli attacchi hanno infettato almeno 953 negozi online. Il meccanismo segnalato prevedeva un blocco CMS di Magento contenente un loader malevolo in grado di recuperare ed eseguire un payload ospitato dall'attaccante. I ricercatori non erano riusciti a recuperare quel payload successivo, lasciando incerto lo scopo ultimo della campagna. Il rapporto descrive l'attività come in corso e ritenuta risalire almeno a luglio 2025.
