CISA aggiunge a KEV il bypass dell'autenticazione MCP di LiteLLM: bastava qualsiasi Bearer Token

Il 2 settembre 2026 la statunitense Cybersecurity and Infrastructure Security Agency ha aggiunto CVE-2026-59822 al proprio catalogo Known Exploited Vulnerabilities come «BerriAI LiteLLM Improper Authentication Vulnerability», una delle sette vulnerabilità del lotto di quel giorno. Il bug si trova nell'endpoint MCP Streamable HTTP di LiteLLM: quando la convalida di una chiave LiteLLM falliva, il fallback passthrough OAuth2 sostituiva un oggetto UserAPIKeyAuth() vuoto invece di rifiutare la richiesta, così qualsiasi intestazione Authorization Bearer inventata apriva una sessione MCP autenticata. Un attaccante che raggiungeva quell'endpoint poteva elencare e richiamare ogni strumento MCP con cui il gateway era configurato e, tramite tali strumenti, raggiungere i servizi dietro di essi. Sono interessate tutte le versioni precedenti alla 1.84.0, e alle agenzie civili federali è stato concesso tempo fino al 16 settembre per porre rimedio. Questo record — l'inserimento nel KEV per il bypass dell'autenticazione MCP di LiteLLM — è una voce in l'OrcaRouter AI Incident Archive, che contiene l'insieme completo dei record e le voci adiacenti a questo incidente.

Il motivo per cui un bug in un proxy conta più di quanto suggerisca il suo punteggio CVSS è ciò che si trova dietro il proxy. Il team di ricerca sulle minacce di Wiz lo dice senza giri di parole: "Un proxy LiteLLM può contenere chiavi per ogni provider di modelli verso cui instrada, inclusi OpenAI, Anthropic, Azure e Gemini. Può anche essere eseguito con autorizzazioni IAM cloud e connettersi a servizi interni tramite server di strumenti MCP. Un'unica compromissione può dare a un attaccante accesso alle credenziali e ai servizi a valle del proxy, non solo al proxy stesso." Wiz Research afferma di aver scoperto la falla, e gli honeypot di Wiz hanno in seguito registrato tentativi di sfruttarla.

Il meccanismo: un controllo non riuscito che ha restituito una sessione valida

L'avviso di BerriAI stesso, GHSA-7488-6r32-c95q, descrive il difetto in due frasi: "Il gestore di autenticazione MCP supportava il passthrough OAuth2 per i server MCP upstream, ma il percorso di fallback poteva sostituire la validazione fallita della chiave LiteLLM con un oggetto UserAPIKeyAuth() vuoto. Ciò consentiva a richieste con un'intestazione Authorization falsificata di raggiungere gli strumenti MCP senza una chiave LiteLLM valida." La parola importante è fallback. Il codice aveva un ramo per le distribuzioni che passano direttamente il token OAuth di un server MCP upstream e, quando una chiave LiteLLM non superava la validazione, quel ramo restituiva un oggetto di autenticazione vuoto anziché un errore.

Un oggetto di autenticazione vuoto non equivale a nessun oggetto di autenticazione. Il codice downstream ha visto un UserAPIKeyAuth costruito con successo ed è proseguito, senza tenant, senza utente e senza alcuno scope associato. L'analisi di Wiz è più schietta sulla conseguenza pratica: «quando la validazione del token fallisce, invece di rifiutare la richiesta, il server restituisce un oggetto UserAPIKeyAuth() vuoto senza restrizioni. Qualsiasi token Bearer (anche solo un singolo carattere, ad es. x) concede pieno accesso MCP.»

Ciò che questo offre a un attaccante è un menu. Il protocollo MCP espone un elenco degli strumenti, quindi una sessione che si autentica restituisce i nomi e gli schemi di ogni strumento che il gateway è stato configurato per raggiungere — database, repository di codice, API interne, negli esempi di Wiz. L'avviso del fornitore dichiara l'effetto in modo chiaro: "Un attaccante potrebbe usarlo per elencare e chiamare gli strumenti MCP configurati e accedere ai servizi connessi esposti tramite MCP." Le chiamate agli strumenti vengono quindi eseguite con qualunque autorità il proxy stesso detenga verso quei backend, che è il problema di concentrazione delle credenziali descritto da Wiz.

Una correzione a maggio, una CVE a luglio, una scadenza federale a settembre

Le date non coincidono come un lettore potrebbe supporre, e sono proprio gli intervalli la parte interessante. LiteLLM 1.84.0 — la prima versione che l'avviso indica come corretta — è stata caricata su PyPI il 14 maggio 2026, secondo i metadati di rilascio dell'indice dei pacchetti stesso. L'identificativo CVE è stato riservato presso il CVE Program il 7 luglio 2026 e il record è stato pubblicato il giorno successivo, l'8 luglio; la voce OSV PYSEC-2026-3479 è seguita il 23 luglio. L'inserimento nel KEV è arrivato il 2 settembre, con una scadenza per la remediation fissata al 16 settembre.

Ne conseguono due cose. Primo, la build corretta era pubblica da più di tre mesi prima che CISA elencasse la vulnerabilità come sfruttata — quindi le organizzazioni vincolate dalla scadenza hanno avuto a disposizione un aggiornamento funzionante per tutto il tempo, e l’aggiunta al KEV non è stato il momento in cui è comparso un fix. Secondo, il divario di versione si è ampliato da allora: l’attuale release di LiteLLM su PyPI è 1.106.5, caricata il 27 ottobre 2026. Un deployment che resta su qualsiasi versione inferiore a 1.84.0 ora è più di venti minor release indietro, non semplicemente a una patch di distanza.

Cosa stabilisce l'annuncio, e cosa no

L'avviso di CISA per il batch afferma che le aggiunte sono effettuate «sulla base di prove di sfruttamento attivo», e la voce leggibile da macchina del catalogo per CVE-2026-59822 riporta una data di aggiunta del 2 settembre 2026, una data di scadenza del 16 settembre 2026, un valore relativo all'uso in campagne ransomware note pari a "Sconosciuto" e due debolezze: CWE-287 (autenticazione impropria) e CWE-306 (autenticazione mancante per una funzione critica).

• Accertato: La CISA ha valutato la vulnerabilità come attivamente sfruttata e l'ha inserita nell'elenco federale per la mitigazione. Il record SSVC dell'NVD, attribuito a un CISA Coordinator e datato 2 settembre 2026, registra lo sfruttamento come "active", l'automazione come "yes" e l'impatto tecnico come "partial".

• Accertato: lo sfruttamento è stato osservato in un ambiente controllato. Wiz ha pubblicato traffico honeypot che mostrava richieste con token di un singolo carattere che sondavano un endpoint di enumerazione dei modelli: una GET a /v1/models con "Authorization: Bearer x". The Hacker News, nel riportare il batch KEV del 3 settembre, ha descritto la stessa attività come l'osservazione, da parte di Wiz, di "tentativi di sfruttamento che coinvolgono CVE-2026-59822 contro i suoi honeypot per sondare gli endpoint di enumerazione dei modelli".

• Stabilito: i punteggi di gravità esistono entrambi e differiscono a seconda del framework. L'avviso di BerriAI classifica la vulnerabilità con CVSS 4.0 a 8.8, alto, con riservatezza alta, integrità bassa e disponibilità nessuna; la valutazione CVSS 3.1 di NIST, che è primaria in NVD, la colloca a 8.2. I due numeri descrivono lo stesso difetto secondo sistemi di punteggio diversi e non dovrebbero essere confrontati come se uno sostituisse l'altro.

• Non stabilito: nessuna vittima nominata. Né l'allerta della CISA, né l'advisory di BerriAI, né il write-up di Wiz, né la copertura di The Hacker News identificano un'organizzazione i cui strumenti MCP siano stati raggiunti tramite questa vulnerabilità, né riportano credenziali o dati sottratti a una di esse. Il registro pubblico dello sfruttamento è telemetria honeypot e una determinazione federale, non una violazione divulgata.

• Non stabilito: che nessun gruppo ransomware lo utilizzi. Il campo KEV riporta "Unknown", un valore assegnato da CISA, non una constatazione di assenza in un senso o nell'altro.

Il precedente di giugno, e la catena di esecuzione di codice remoto che questo non è

Questa è la seconda vulnerabilità di LiteLLM a raggiungere il catalogo KEV nel 2026, ed è facile confonderla con quella precedente. CVE-2026-42271, aggiunta l'8 giugno 2026 con scadenza il 22 giugno, è un'iniezione di comandi negli endpoint di test del server MCP di LiteLLM: Wiz descrive endpoint che consentono a un utente di testare una configurazione del server MCP prima di salvarla, con il campo command passato all'esecuzione di un sottoprocesso senza validazione. Gli attaccanti hanno inviato una configurazione fittizia di server stdio il cui comando scaricava ed eseguiva un cryptominer, e restituivano un handshake MCP dall'aspetto valido affinché il test sembrasse riuscito. La voce della CISA per questa vulnerabilità elenca CWE-78 e CWE-77 — iniezione di comandi e argomenti, non autenticazione.

Quella falla è quella che si concatena. Wiz afferma che CVE-2026-42271 "può essere concatenata con un bypass della validazione dell'header host di Starlette (CVE-2026-48710) per ottenere un RCE completamente non autenticato", e che ricercatori esterni hanno collegato il gruppo ransomware Qilin allo sfruttamento attivo di quella catena. CVE-2026-48710 è stata aggiunta al catalogo KEV nello stesso lotto del 2 settembre del bypass di LiteLLM, con la stessa scadenza del 16 settembre, e la nota del catalogo di CISA relativa alla falla di Starlette afferma che potrebbe essere concatenata con CVE-2026-42271. Il collegamento a Qilin appartiene a quella combinazione. Non è un risultato riguardante CVE-2026-59822, e nulla nelle fonti esaminate collega il gruppo ransomware al bypass dell'autenticazione.

Un dettaglio amministrativo distingue le due voci di LiteLLM: l'azione richiesta nell'elenco di giugno cita la BOD 22-01, la più vecchia direttiva operativa vincolante, mentre l'elenco di settembre cita la BOD 26-04, "Prioritizing Security Updates Based on Risk". L'avviso della CISA non spiega il cambiamento e il catalogo non lo annota.

Cosa è cambiato dopo

Il percorso di correzione è breve. L'avviso di BerriAI raccomanda di aggiornare alla versione 1.84.0 o successiva e offre una soluzione alternativa per i team che non possono passare subito: "disabilitare le rotte MCP o bloccare l'accesso a /mcp/ e agli endpoint MCP correlati sul reverse proxy o sull'API gateway." Quella soluzione alternativa è uno strumento grossolano — rimuove la funzionalità invece di limitarne l'accesso — ma è l'unica mitigazione che il fornitore indica per le distribuzioni non aggiornate.

Il testo dell'azione richiesta dalla CISA per le voci inserite pone le agenzie federali davanti allo stesso compromesso: applicare le mitigazioni secondo le istruzioni del fornitore e in linea con la BOD 26-04, «oppure interrompere l'uso del prodotto se le mitigazioni non sono disponibili», con la responsabilità, in capo a ciascuna agenzia, di valutare l'esposizione di un asset a Internet. La direttiva è vincolante solo per le agenzie civili del ramo esecutivo federale; la CISA incoraggia altre organizzazioni ad adottare la stessa prioritizzazione basata sul rischio, senza renderla obbligatoria.

Non è pubblico se qualcuno al di fuori di un honeypot abbia agito entro la scadenza. Né CISA né BerriAI hanno pubblicato cifre su quante distribuzioni LiteLLM siano state esposte, quante siano state sottoposte a patch prima del 16 settembre o quante siano state raggiunte tramite il bypass.

Cosa resta aperto

Tre lacune meritano di essere dichiarate anziché mascherate. Non esiste alcun rapporto pubblico su un incidente che colleghi CVE-2026-59822 a una specifica intrusione, quindi l'inserimento in KEV si basa sulle prove di sfruttamento della CISA e sulle osservazioni honeypot di Wiz, non su una vittima documentata. Non esiste una dichiarazione del fornitore su come il percorso di fallback sia stato scritto in quel modo, né su quanto tempo sia esistito prima della 1.84.0: l'avviso descrive il difetto e la sua correzione, non la sua storia. E le scadenze del lotto non erano uniformi: cinque delle sette voci aggiunte il 2 settembre avevano una scadenza al 5 settembre, mentre le voci relative a LiteLLM e Starlette avevano una scadenza al 16 settembre. La CISA non dice perché.

Ciò che è accertato è più circoscritto e più utile del punteggio. Un singolo carattere in un header Authorization era, sulle versioni interessate, indistinguibile da una chiave valida per l'endpoint MCP — e le versioni che si comportavano così hanno smesso di essere quelle attuali nel maggio 2026.