LiteLLM CVE-2026-42271: l'AI gateway è una superficie RCE

Quasi ogni azienda che negli ultimi diciotto mesi ha rilasciato una funzionalità basata su LLM ha messo un gateway davanti. Quel gateway custodisce le API key di OpenAI, Anthropic, Azure e di una decina di modelli self-hosted; gestisce budget, rotazione delle chiavi, logging delle richieste e fallback routing. È, per costruzione, l'unico host che può parlare con ogni provider di modelli e che vede ogni prompt. In molte organizzazioni è stato tirato su da un team di piattaforma in un pomeriggio, esposto su un load balancer interno e mai inserito nell'inventario degli asset. L'8 giugno 2026 CISA ha aggiunto CVE-2026-42271 — una command injection in LiteLLM, l'AI gateway open-source più diffuso — al proprio catalogo Known Exploited Vulnerabilities, con scadenza di remediation federale al 22 giugno. Una settimana dopo, il 15 giugno, un secondo gruppo di ricerca ha pubblicato una catena che porta una chiave a bassi privilegi fino all'esecuzione di codice remoto. L'AI gateway non è più impianto idraulico. È un bersaglio.

Cos'è davvero CVE-2026-42271

LiteLLM espone due endpoint pensati per consentire a un operatore di fare anteprima di un server MCP (Model Context Protocol) prima di salvarlo: POST /mcp-rest/test/connection e POST /mcp-rest/test/tools/list. Per testare un server MCP che usa il transport stdio, quegli endpoint accettano una configurazione completa del server — inclusi i campi command, args ed env — e poi avviano quel comando come sottoprocesso sull'host del proxy per vedere se risponde. Non c'è alcuna allow-list. Qualunque binario e qualunque argomento invii, il gateway li esegue.

È tutto qui il bug. Secondo la scheda NVD, è classificato CWE-77 / CWE-78 (OS command injection), valutato CVSS 3.1 8.8 e CVSS 4.0 8.7, e affligge LiteLLM dalla 1.74.2 alla 1.83.6. BerriAI, il manutentore, ha rilasciato la correzione nella v1.83.7-stable l'8 maggio 2026. La falla era inizialmente classificata come autenticata, perché raggiungere gli endpoint di test MCP richiedeva una proxy API key valida. In un gateway multi-tenant dove ogni sviluppatore ha una chiave, "autenticato" è già un muro sottile. E si è rivelato più sottile di così.

Da autenticata a non autenticata: la catena Starlette

LiteLLM è costruito su Starlette, il framework ASGI che sta sotto FastAPI. Il 26 maggio 2026, CVE-2026-48710 — soprannominata "BadHost" — ha reso pubblico un bypass della validazione dell'header Host in Starlette fino alla versione 1.0.0. Horizon3.ai ha collegato i due punti: se l'albero delle dipendenze di un'installazione LiteLLM include una versione vulnerabile di Starlette, un attaccante può manipolare l'header HTTP Host per bypassare del tutto il controllo dell'API key di LiteLLM, e poi chiamare gli endpoint di test MCP senza alcuna credenziale.

Horizon3.ai ha validato l'intera catena il 1° giugno 2026 e la valuta CVSS 10.0. L'impatto pubblicato sembra una slide di briefing nel caso peggiore:

• eseguire comandi arbitrari sull'host LiteLLM;
• leggere le credenziali dei provider di modelli che il gateway custodisce;
• sottrarre le API key e i segreti che gestisce per conto di ogni applicazione a valle;
• muoversi lateralmente nell'infrastruttura AI a cui il gateway è collegato.

La remediation ha due lati: aggiornare LiteLLM alla 1.83.7 o successiva e Starlette alla 1.0.1 o successiva. Correggere solo l'applicazione lascia vivo il bypass dell'header Host nella dipendenza che non avevi pensato di controllare.

L'escalation del 15 giugno: da chiave a bassi privilegi a proxy admin

Il pezzo più fresco è arrivato ieri. Il 15 giugno 2026, Obsidian Security ha reso pubblica una catena separata e autenticata che raggiunge lo stesso primitivo di command injection dall'interno — utile esattamente in quelle installazioni multi-tenant dove il bypass non autenticato è già corretto ma gli utenti ordinari hanno comunque le chiavi. The Hacker News ha coperto la disclosure; la catena è valutata CVSS 9.9 e impila tre falle:

CVE	Classe	Meccanismo
CVE-2026-47101	Authorization bypass	Quando un utente normale genera una virtual key, LiteLLM salva il campo allowed_routes fornito dal chiamante senza verificarlo rispetto al ruolo. Un non-admin può emettere una chiave con allowed_routes: ["/*"] — un wildcard che raggiunge le route riservate agli admin.
CVE-2026-47102	Privilege escalation	/user/update consente a un utente di modificare il proprio record senza limitare i campi scrivibili. Un self-update con user_role: "proxy_admin" promuove il chiamante a proxy admin completo.
CVE-2026-42271	Command injection	Con i privilegi di admin, gli endpoint di test MCP avviano un comando fornito dall'attaccante — la reverse shell.

Tre bug di logica, nessuno esotico: un controllo di ruolo mancante su un campo, un self-update troppo permissivo e un endpoint che si fida del proprio input. Concatenati, trasformano qualunque sviluppatore in grado di autenticarsi sul gateway in root-equivalent sull'host che custodisce le chiavi dei tuoi modelli. Il set completo di correzioni è arrivato in build stabili 1.83.x successive; se a maggio hai applicato la patch per la command injection ma non hai seguito i fix di autorizzazione, non hai finito.

Perché l'AI gateway è l'host peggiore da perdere

Trattalo come una RCE qualsiasi e ne sottovaluterai la portata. L'host LiteLLM non è un web server che puoi reimmaginare e dimenticare. Secondo il suo repository GitHub, LiteLLM conta circa 47.800 stelle e oltre 21.000 progetti dipendenti, e gira in produzione presso organizzazioni come Netflix, Lemonade e Rocket Money. La ragione per cui è ovunque è la stessa per cui la sua compromissione è grave: è l'unico punto in cui ogni credenziale di provider è concentrata e in cui passa ogni prompt e ogni completion.

"Dopo l'incidente abbiamo ruotato la chiave OpenAI. Non ci eravamo resi conto che il gateway mediava anche il ruolo Bedrock, le chiavi di deployment Azure, tre endpoint vLLM interni e i server MCP che chiamano i nostri agent. L'attaccante aveva trenta minuti di vantaggio su un host che non avevamo mai scansionato, perché non era nella CMDB."

Quel controfattuale è l'intero problema. Un attaccante sul gateway non ottiene solo la macchina. Ottiene un caveau di credenziali per l'intero parco modelli, un punto di osservazione su ogni prompt (compresi i dati sensibili che gli utenti incollano) e — attraverso lo stesso meccanismo MCP che il bug abusa — un punto d'appoggio nell'infrastruttura di tool-calling che i tuoi agent usano per toccare database, sistemi di ticketing e API interne. MCP è il tessuto connettivo dell'AI agentica; una RCE che vive nel percorso di anteprima MCP ti deposita nel mezzo di quel tessuto.

L'asset che nessuno ha inventariato

La parte scomoda non sono i tre bug di logica. È il divario di cadenza che li ha lasciati esposti. Gli AI gateway hanno un problema di discovery che le infrastrutture più vecchie non hanno:

• Nascono fuori dal change control. Un team di piattaforma o data science tira su LiteLLM per sbloccare una funzionalità. Raramente entra nell'inventario degli asset, quindi la scansione trimestrale e il pentest annuale non lo vedono mai.
• Sono raggiungibili da internet più spesso di quanto si ammetta. Molte istanze LiteLLM stanno dietro nient'altro che un controllo di API key — che CVE-2026-48710 rimuove — su host raggiungibili dalla rete pubblica o da una rete interna piatta.
• Si muovono in fretta. LiteLLM ha rilasciato oltre mille versioni; quella che hai valutato due mesi fa non è quella in esecuzione oggi. Il fix della command injection (1.83.7) e i fix di autorizzazione sono usciti a settimane di distanza. Un test puntuale antecedente a entrambi è cieco.
• Gli scanner convenzionali non li modellano. Uno scanner di rete vede un servizio HTTP su una porta. Non sa che /mcp-rest/test/connection avvierà un sottoprocesso, né che un wildcard allowed_routes è un primitivo di privilege escalation. La vulnerabilità è nella logica applicativa, non in un banner.

Il risultato è una classe di host ad alto valore esposti, in rapido movimento e assenti dagli stessi inventari su cui è costruito il tuo programma di validazione. Quando l'8 giugno CVE-2026-42271 è arrivata nel catalogo KEV, la domanda rilevante per la maggior parte dei team non era "è patchata" — era "sappiamo almeno dove sono le nostre istanze LiteLLM".

Dove tutto questo lascia la validazione continua

La risposta difendibile a una superficie RCE rapida, non inventariata ed esposta su internet non è un pentest annuale più veloce. È una validazione che trova l'asset e prova la catena di exploit prima che lo faccia un attaccante — ed è esattamente la domanda operativa a cui risponde il pilastro di pentest generativo di Zero Hunt.

Zero Hunt esegue campagne change-triggered: quando un nuovo servizio compare sul perimetro — inclusa una gateway LiteLLM appena tirata su — scatta una campagna completa entro un'ora, invece di aspettare la finestra programmata successiva. Lo swarm di 10 agent (Recon, Exploit, Web, Credential, Post-Exploit, Pivot, Tactic, Report, sotto un AI Controller) fa poi ciò che una scansione di banner non può: gli agent Web ed Exploit ragionano sulla logica applicativa, sondano un endpoint come /mcp-rest/test/connection per il comportamento di spawn di sottoprocessi che vi sta dietro, e scrivono un exploit per-target con un LLM locale invece di scaricare un PoC generico. Le nuove skill offensive sono backtestate nell'AI Gym — contro Vulhub, NYU CTF Bench, Cybench e un corpus black-box basato su CVE — prima di toccare un ambiente di produzione, così la catena eseguita contro la tua gateway è già stata provata sicura in sandbox. Ogni finding è firmato ECDSA al momento della scrittura, il che conta quando l'host che hai appena dimostrato exploitabile custodisce le chiavi dell'intero parco modelli e prima o poi qualcuno chiederà le prove.

Il pilastro complementare è sul filo della rete. L'exploitation qui termina in un sottoprocesso: una reverse shell, una curl verso un IP esterno, un beacon in uscita da un host la cui intera vita precedente è stata fare da proxy di richieste verso i provider di modelli. L'AI Traffic Analysis di Zero Hunt — un modello di deep learning con quattro inference head che gira sulla GPU dell'appliance — è costruito per segnalare proprio questo: un proxy che improvvisamente apre una sessione in uscita verso un ASN mai visto, il pivot laterale dal gateway verso l'infrastruttura AI collegata, l'egress che non corrisponde al baseline dell'host. Vede la conseguenza della RCE mentre accade, non nella revisione dei log del mattino dopo. Trova la gateway prima dell'attaccante e applichi la patch. La manchi, e il traffico resta il testimone. Entrambi girano su un'appliance 100% on-prem — nessuna callback cloud, nessun prompt né chiave che lascia la tua rete verso terzi, che per l'host che media l'intero stack AI è l'unica postura accettabile.

Se gestisci funzionalità LLM, l'azione è concreta: trova ogni istanza LiteLLM, verifica che sia su 1.83.7+ con Starlette 1.0.1+, e controlla anche i fix di autorizzazione — non solo quello della command injection. Poi poniti la domanda più difficile: come avresti trovato quell'host se non fosse mai entrato nell'inventario. Parla con noi se la risposta onesta è "non l'avremmo trovato".