LiteLLM, chiave esposta apre la strada al malware: Brotli colpisce Node.js

🛡️ Executive Summary

• LiteLLM conferma che una master key pubblicata accidentalmente a maggio e mai revocata ha permesso il furto di tre token GitHub e la distribuzione della release malevola 1.107.0.
• Imperva dimostra l’esecuzione di codice attraverso CVE-2026-111497 su Node.js 24.22.0: il difetto riguarda il decoder Brotli condiviso da numerosi software.
• Le correzioni coinvolgono Node.js, Bun, Python, Envoy e Istio. Non risultano campagne di sfruttamento attivo della vulnerabilità Brotli.

Una chiave dimenticata in un repository pubblico ha permesso agli aggressori di compromettere la supply chain LiteLLM, mentre una vulnerabilità nel decoder Brotli espone a potenziale esecuzione remota di codice numerose piattaforme applicative. Le nuove informazioni pubblicate il 23 e 24 ottobre 2026 modificano il quadro dei due incidenti: LiteLLM ha ricostruito l’origine effettiva delle credenziali utilizzate per distribuire il malware, correggendo le ipotesi iniziali sul furto dei token GitHub, mentre Imperva ha dimostrato una RCE su una build ufficiale di Node.js. La falla Brotli, identificata come CVE-2026-111497, non riguarda soltanto il runtime JavaScript, ma anche Bun, librerie Python e proxy Envoy che utilizzano il componente vulnerabile.

LiteLLM conferma una master key esposta dal 27 maggio e mai revocata

La ricostruzione definitiva pubblicata dal team LiteLLM identifica l’origine della compromissione nel repository pubblico LiteLLM-Labs/lite-harness, dove il 27 maggio 2026 era stato pubblicato accidentalmente un file opencode.json contenente la master key di un’installazione sperimentale della LiteLLM Agent Platform. Gli sviluppatori avevano individuato rapidamente l’errore e riscritto la cronologia Git per eliminare il file, ma non avevano revocato la credenziale, che rimaneva quindi utilizzabile da chiunque ne avesse conservato una copia. Il 10 ottobre un aggressore ha impiegato quella chiave per interrogare le API della piattaforma e recuperare la configurazione degli agenti gestiti. La risposta conteneva un token OAuth di GitHub CLI appartenente a un proprietario dell’organizzazione, dotato di privilegi estesi sui repository. Questo passaggio corregge le precedenti ipotesi secondo cui i token sarebbero stati sottratti direttamente dai log delle risposte generate da Claude Code: il vettore iniziale accertato è la chiave esposta nel repository pubblico. Il precedente incidente LiteLLM collegato a OpenCode e al furto dei token GitHub aveva già evidenziato il problema delle credenziali negli ambienti AI, ma la nuova cronologia individua con maggiore precisione la prima compromissione.

Leggi anche: LiteLLM espone il control plane AI a RCE e furto di chiavi

Tre token GitHub consentono di firmare e pubblicare una release malevola

Ottenuto l’accesso privilegiato, l’aggressore ha utilizzato workflow GitHub Actions temporanei per sottrarre altri due token appartenenti a manutentori LiteLLM. Il 21 ottobre ha tentato di modificare il repository privato BerriAI/project-releaser, incontrando inizialmente il blocco delle protezioni sul ramo principale. Il token del proprietario dell’organizzazione ha però consentito di superare quelle restrizioni e indirizzare la pipeline verso un repository contraffatto, Berri-AI/litellm, distinto dall’originale BerriAI/litellm. Un secondo token è servito ad approvare il rilascio in produzione, mentre il terzo ha permesso di cancellare i registri dei workflow, ostacolando le verifiche. La pipeline legittima ha quindi firmato e distribuito LiteLLM 1.107.0 contenente uno stealer e componenti per l’esecuzione remota di codice. I sette pacchetti PyPI compromessi sono rimasti disponibili dalle 11:39 alle 13:23 UTC, mentre alcune immagini Docker sono state esposte fino alle 14:20 UTC. Il codice sorgente ufficiale della release non conteneva i file malevoli, perché gli artefatti erano stati costruiti dal repository controllato dagli aggressori. La comunicazione ufficiale di contenimento indica come misura necessaria la ricostruzione degli ambienti interessati e la rotazione delle credenziali accessibili ai processi compromessi: la semplice rimozione del pacchetto non elimina gli effetti del furto. La vicenda rafforza il problema già emerso nelle precedenti compromissioni della supply chain LiteLLM, ma senza dimostrare un collegamento fra gli autori delle diverse campagne.

Brotli CVE-2026-111497 permette una RCE dimostrata su Node.js

Il secondo sviluppo riguarda CVE-2026-111497, vulnerabilità nel decoder Brotli di Google utilizzato per decomprimere dati HTTP. Il problema consiste in una scrittura fuori dai limiti di un buffer, provocata dalla gestione scorretta di uno stato non valido durante la decodifica di un flusso compresso. Il progetto Node.js aveva già distribuito il 21 ottobre le correzioni nelle versioni 22.23.4, 24.22.1 e 26.12.1, ma le nuove verifiche mostrano che il rischio RCE non è soltanto teorico. Nella dimostrazione tecnica Node2Shell pubblicata da Imperva, i ricercatori hanno eseguito codice attraverso dati Brotli malevoli su una build ufficiale Node.js 24.22.0 per Linux ARM64, senza modificare il binario o utilizzare un debugger. L’attacco è stato riprodotto sia attraverso risposte HTTP ottenute dall’applicazione sia mediante richieste elaborate da Express e body-parser. L’esecuzione non è riuscita a ogni tentativo e non è stata dimostrata su tutte le architetture o release vulnerabili. La versione corretta 24.22.1 ha invece rifiutato gli stessi dati senza eseguire il payload. La ricerca amplia quanto già documentato nell’approfondimento sulle vulnerabilità GitLab, Node.js e HTTP/3, introducendo una prova concreta di sfruttabilità in ambiente reale. Non risultano tuttavia campagne offensive confermate né una diffusione pubblica dell’exploit Imperva.

Python, Bun ed Envoy ereditano il problema dalla libreria Brotli

La vulnerabilità non nasce nel codice applicativo di Node.js, ma nella libreria condivisa da numerosi progetti. L’advisory di sicurezza di Bun conferma che le versioni precedenti alla 1.4.4 incorporano un decoder vulnerabile, raggiungibile attraverso fetch(), node:zlib e altre API di decompressione. La correzione richiede anche la ricompilazione degli eseguibili prodotti con bun build --compile, perché contengono una copia del runtime. In ambito Python sono interessati i pacchetti Brotli, corretti nella versione 1.2.1, e brotlicffi, aggiornato alla 1.2.1.0. Il rischio può manifestarsi anche nelle applicazioni che non importano direttamente queste librerie, perché client HTTP come requests, urllib3 e httpx possono utilizzarle automaticamente quando ricevono risposte con Content-Encoding: br. La comunicazione di sicurezza Envoy identifica invece come vulnerabili le installazioni che hanno configurato il decompressor Brotli, corrette nelle versioni 1.40.0, 1.39.3, 1.38.6, 1.37.8 e 1.36.12. Anche Istio ha distribuito aggiornamenti, mentre Debian 13 Trixie ha corretto il pacchetto Brotli nella versione 1.1.0-2+deb13u1, secondo il bollettino DSA-6582-1. Il dato operativo più importante riguarda la superficie esposta: un’applicazione è vulnerabile quando decomprime dati Brotli controllabili da un aggressore, non semplicemente perché utilizza HTTP o perché la libreria è presente tra le dipendenze.

Continua con:

PoeLLM infetta oltre 3.400 server AI esposti e li trasforma in miner

Due incidenti diversi mostrano i rischi nascosti nelle dipendenze software

LiteLLM e Brotli richiedono risposte differenti, ma evidenziano lo stesso problema di fondo: la sicurezza di un’applicazione dipende anche da componenti e privilegi che non sono immediatamente visibili nel codice principale. Per LiteLLM occorre identificare le installazioni della release 1.107.0, evitare di riavviare Python negli ambienti sospetti prima della bonifica, ricostruire container e virtual environment e revocare chiavi AI, token GitHub e credenziali cloud potenzialmente esposte. Per Brotli è necessario aggiornare runtime, librerie e immagini container, verificando che i processi in esecuzione utilizzino effettivamente la versione corretta. Dove non è possibile intervenire immediatamente, occorre evitare la decompressione di contenuti Brotli provenienti da sorgenti non attendibili, senza considerare il semplice blocco delle richieste HTTP in ingresso una difesa sufficiente contro le risposte ricevute da server esterni. La compromissione LiteLLM è un incidente supply chain realmente avvenuto; la falla Brotli è una vulnerabilità con RCE dimostrata in laboratorio, ma senza attacchi pubblicamente confermati. La distinzione serve a stabilire priorità adeguate e conferma che controllare le dipendenze significa verificare non soltanto quali pacchetti siano installati, ma anche quali credenziali custodiscano, quali privilegi possiedano e quali dati esterni siano autorizzati a elaborare.