In sintesi
La CVE-2026-59822 è una vulnerabilità di autenticazione di gravità alta (CVSS 8,8) nell'endpoint MCP Streamable HTTP di LiteLLM; l'agenzia statunitense CISA l'ha inserita a inizio settembre 2026 nel suo catalogo delle vulnerabilità sfruttate attivamente (KEV), con scadenza per la patch al 16 settembre. Prima di LiteLLM 1.84.0 un attaccante non autenticato poteva inviare un header Authorization contraffatto che attivava un fallback OAuth2 passthrough, sostituiva la verifica della chiave fallita con un oggetto di autenticazione vuoto e raggiungeva così gli strumenti collegati al gateway tramite il Model Context Protocol. La soluzione: aggiornare alla 1.84.0 e blindare l'endpoint. Se i vostri modelli passano da un gateway LLM nell'ambito di un'integrazione di IA generativa, applicate la patch adesso – e trattate il gateway come infrastruttura di produzione, non come un servizio accessorio.
Cosa fa esattamente la CVE-2026-59822
LiteLLM, sviluppato da BerriAI, è uno dei gateway IA open source più diffusi: un proxy che offre ai team un'unica API compatibile con OpenAI davanti a decine di provider di modelli, con gestione delle chiavi, budget, routing e logging in un solo punto. Le versioni recenti supportano anche il Model Context Protocol (MCP), lo standard emergente con cui un LLM richiama strumenti e fonti dati esterne. La CVE-2026-59822 si trova proprio in questo punto di giunzione – l'endpoint MCP Streamable HTTP – e ha un punteggio CVSS di 8,8 (alto).
Il meccanismo è un caso da manuale di fallback di autenticazione difettoso. Nelle versioni di LiteLLM precedenti alla 1.84.0, una richiesta all'endpoint MCP con un header Authorization contraffatto falliva la normale validazione della chiave, ma invece di essere respinta ricadeva in un percorso OAuth2 passthrough. Quel percorso sostituiva la verifica fallita con un oggetto utente autenticato vuoto: la richiesta veniva considerata valida e proseguiva. Risultato: un chiamante non autenticato, con un qualsiasi token Bearer arbitrario, poteva aprire una sessione MCP autenticata, elencare gli strumenti esposti dal gateway, richiamarli e raggiungere tutti i servizi a valle a cui sono collegati.
La CISA non inserisce falle nel catalogo KEV per ipotesi: servono prove di sfruttamento attivo. La CVE-2026-59822 è una delle sette vulnerabilità aggiunte a inizio settembre 2026, con scadenza di correzione al 16 settembre per le agenzie civili federali statunitensi. A colpire è la composizione del gruppo: tre delle sette aggiunte riguardavano l'infrastruttura IA, non i soliti VPN, server di posta e applicazioni web. È il segnale da leggere con attenzione: l'infrastruttura IA è diventata una categoria ordinaria di sistemi sfruttati, e una scadenza di patch rigida sul gateway LLM di un'azienda ne è la conseguenza pratica.
Perché il bersaglio è il gateway IA
Si potrebbe archiviare il caso come «l'ennesima CVE», ma conta più il punto colpito che il meccanismo. Un gateway IA non è un servizio periferico: è un collo di bottiglia che concentra potere. Per fare il suo lavoro conserva le chiavi API di tutti i provider di modelli, gestisce budget e regole di routing dell'intera organizzazione e, una volta attivato MCP, media l'accesso agli strumenti e alle fonti dati che i modelli possono usare. Compromettere il gateway non significa violare un'applicazione: significa arrivare alle credenziali e alla superficie di strumenti di tutto ciò che vi transita.
MCP rende il quadro più critico. Il protocollo esiste perché un LLM possa elencare e invocare strumenti – una query sul database, un client per un'API interna, un lettore di file – e ognuno di questi strumenti è una porta verso un sistema reale. Un aggiramento dell'autenticazione sull'endpoint MCP non significa quindi «un attaccante può chattare con il vostro modello», ma «un attaccante può richiamare gli strumenti che il vostro modello può richiamare», con tutti i permessi concessi. Per i team che sviluppano agenti IA è il nocciolo della questione: nello strato degli strumenti risiede la reale capacità d'azione di un agente – e il suo raggio d'impatto. Una falla che consegna questo strato a un chiamante anonimo somiglia più al furto di un account di servizio che alla fuga di un prompt.
Cosa cambia per i team negli Stati Uniti e nell'UE
Primo: verificate se usate LiteLLM e in quale versione. Poiché un gateway LLM si avvia in pochi minuti, spesso arriva senza un responsabile formale – un proof of concept del team data science, un container in un namespace di piattaforma, una dipendenza dentro un prodotto IA più ampio. Ogni installazione precedente alla 1.84.0 che espone l'endpoint MCP è coinvolta. Aggiornate alla 1.84.0 o successiva e verificatelo come qualsiasi voce del KEV: con un inventario, non con una speranza. La scadenza federale del 16 settembre è un obiettivo interno ragionevole anche senza obblighi di conformità.
Secondo: smettete di considerare il gateway IA una comodità e trattatelo da infrastruttura. Gli endpoint MCP e di amministrazione non devono essere raggiungibili da reti non fidate e vanno protetti da autenticazione reale e controlli di rete, invece di affidarsi alla sola verifica della chiave del gateway – questa falla ricorda che un singolo controllo applicativo può fallire in modalità aperta. Applicate il minimo privilegio a ogni collegamento di strumenti MCP, così che anche un aggiramento riuscito raggiunga il meno possibile, e ruotate le chiavi dei provider salvate nel gateway se non potete escludere un'esposizione. In contesti regolamentati – un prodotto FinTech o HealthTech i cui strumenti toccano dati dei clienti – un accesso non autenticato a quegli strumenti diventa rapidamente un incidente da notificare.
Terzo: inserite l'infrastruttura IA nella stessa cadenza di patch del resto dello stack. Se tre aggiunte su sette al KEV sono componenti IA, la lezione è che gateway, server di orchestrazione e framework per agenti vengono attaccati come qualsiasi altro servizio esposto. Tenere LiteLLM e simili al massimo una o due release indietro e tracciarne le versioni nella gestione delle vulnerabilità trasforma la prossima CVE dell'infrastruttura IA in un aggiornamento di routine anziché in un'emergenza.
Cosa significa per il mercato italiano?
In Italia i gateway LLM come LiteLLM compaiono sempre più spesso nei progetti di IA generativa di banche, assicurazioni, PMI manifatturiere e system integrator, perché permettono di usare più provider dietro un'unica interfaccia e di instradare i dati sensibili verso modelli ospitati in cloud europei o on-premise. Proprio perché nasce spesso come progetto pilota, il gateway rischia di restare fuori dall'inventario degli asset e dai cicli di patch.
Il quadro normativo è chiaro. Se tramite uno strumento MCP vengono raggiunti dati personali, la violazione va notificata al Garante per la protezione dei dati personali entro 72 ore (art. 33 GDPR). Per i soggetti che rientrano nel perimetro NIS2, recepita in Italia con il D.Lgs. 138/2024, un incidente significativo richiede una pre-notifica al CSIRT Italia entro 24 ore; per banche e intermediari finanziari si aggiungono gli obblighi di segnalazione previsti dal regolamento DORA. Sul fronte operativo, l'Agenzia per la Cybersicurezza Nazionale (ACN) e il CSIRT Italia pubblicano avvisi sulle vulnerabilità sfruttate attivamente: vale la pena seguirli insieme al catalogo KEV. In pratica, il gateway IA va iscritto nell'inventario degli asset, nella gestione delle vulnerabilità e nel perimetro degli audit di sicurezza.
La checklist della settimana
- Censire i gateway. Trovare ogni installazione di LiteLLM – comprese quelle «ombra» in PoC e namespace di piattaforma – e registrarne versione e responsabile.
- Aggiornare alla 1.84.0+. Correggere ogni versione precedente che espone l'endpoint MCP Streamable HTTP e verificare il rispetto della scadenza del 16 settembre.
- Chiudere l'endpoint. Mettere gli endpoint MCP e di amministrazione dietro controlli di rete e autenticazione forte; nessuna esposizione verso reti non fidate.
- Minimo privilegio per gli strumenti. Rivedere cosa può raggiungere ogni strumento MCP collegato e ridurlo al minimo indispensabile.
- Ruotare e controllare. Ruotare le chiavi API dei provider salvate nel gateway se non si può escludere un'esposizione, cercare nei log richieste con header Authorization malformato sulla rotta MCP e valutare gli obblighi di notifica verso Garante e CSIRT Italia.
- L'infrastruttura IA nella cadenza. Tracciare le versioni di gateway e framework nella gestione delle vulnerabilità, così che la prossima CVE sia routine.
Domande frequenti
Che cos'è la CVE-2026-59822 in LiteLLM?
La CVE-2026-59822 è una vulnerabilità di autenticazione nell'endpoint MCP (Model Context Protocol) Streamable HTTP di LiteLLM, il gateway e proxy IA open source di BerriAI. Ha un punteggio CVSS di 8,8 (alto). Prima della versione 1.84.0 un attaccante non autenticato poteva inviare un header Authorization contraffatto che attivava un fallback OAuth2 passthrough. Quel percorso sostituiva la verifica della chiave fallita con un oggetto di autenticazione vuoto, così la richiesta raggiungeva gli strumenti MCP senza una chiave LiteLLM valida. Da lì l'attaccante poteva elencare e richiamare gli strumenti configurati e accedere ai servizi a cui sono collegati.
Quali versioni di LiteLLM sono coinvolte e come si corregge?
La falla riguarda le versioni di LiteLLM precedenti alla 1.84.0 che espongono l'endpoint MCP Streamable HTTP. La correzione è aggiornare a LiteLLM 1.84.0 o successiva. Oltre all'aggiornamento, occorre rendere gli endpoint MCP e di amministrazione irraggiungibili da reti non fidate, censire i permessi di ogni strumento MCP collegato e controllare i log alla ricerca di richieste con header Authorization anomali o malformati.
Perché una falla di un gateway IA nel catalogo KEV è così seria?
La CISA inserisce una vulnerabilità nel catalogo Known Exploited Vulnerabilities solo quando ha prove di sfruttamento attivo. L'inserimento fissa una scadenza di patch per le agenzie federali statunitensi, che anche le aziende europee dovrebbero considerare un segnale forte. La CVE-2026-59822 è una delle sette falle aggiunte a inizio settembre 2026, tre delle quali riguardavano l'infrastruttura IA: gateway, server di orchestrazione e strumenti MCP sono ormai un bersaglio ordinario.
Come mettere in sicurezza LiteLLM e gli endpoint MCP?
Trattare il gateway IA come infrastruttura di produzione: aggiornarlo con cadenza regolare, restare al massimo una o due release indietro, mettere ogni endpoint MCP e di amministrazione dietro controlli di rete e autenticazione forte invece di affidarsi solo alla verifica della chiave del gateway. Applicare il minimo privilegio a ogni strumento MCP, ruotare le chiavi API dei provider salvate nel gateway e inserire le versioni di gateway e framework nel processo di gestione delle vulnerabilità.
Fonti
CISA – Known Exploited Vulnerabilities Catalog (fonte primaria, inserimento a inizio settembre 2026)
The Hacker News – CISA Adds Seven Exploited Flaws as Attackers Deploy Reverse Shells and Crypto Miners (settembre 2026)
GitLab Advisory Database – CVE-2026-59822: LiteLLM MCP Authentication Bypass via OAuth2 Passthrough Fallback