Allarme rosso per LiteLLM e Starlette: la combo letale che apre la porta all'esecuzione di codice da remoto

• POST /mcp-rest/test/connection

• POST /mcp-rest/test/tools/list

Entrambi accettano una configurazione completa del server MCP nel corpo della richiesta JSON, inclusi i campi Cmd, args ed env che il trasporto stdio utilizza per avviare i processi del server. Quando un utente autenticato chiama uno di questi endpoint con questa configurazione, LiteLLM prende il valore Cmd fornito e lo esegue come sottoprocesso sulla macchina host, con gli stessi privilegi di sistema del processo proxy LiteLLM stesso .

Inizialmente, BerriAI aveva divulgato la cosa come un bug di esecuzione codice remoto autenticato: un attaccante aveva bisogno di una chiave API valida per raggiungere gli endpoint, e non c'era alcun controllo basato sui ruoli. Anche un utente interno con privilegi minimi e una qualsiasi chiave API proxy valida poteva eseguire comandi arbitrari sull'host . Ma la storia non finisce qui.

Il bypass BadHost di Starlette che rimuove il requisito di autenticazione

La seconda vulnerabilità è CVE-2026-48710, soprannominata "BadHost" dai ricercatori. Si tratta di una falla nella convalida dell'header Host in Starlette, il leggero framework ASGI che è alla base di FastAPI, vLLM e migliaia di altre applicazioni web Python, inclusa LiteLLM . Sono interessate tutte le versioni di Starlette dalla 0.8.3 alla 1.0.0 .

La causa principale è un disaccordo di interpretazione (parser disagreement) tra il modo in cui Starlette smista le richieste in arrivo e il modo in cui ricostruisce l'URL per la logica applicativa . Il livello di routing ASGI usa il percorso HTTP grezzo della richiesta per decidere quale endpoint gestirla. Ma request.url — l'URL che il middleware e i decoratori dell'applicazione vedono — viene ricostruito concatenando il valore grezzo dell'header Host con il percorso della richiesta, senza una convalida adeguata .

Iniettando caratteri delimitatori come ? o # nell'header Host, un attaccante può far sì che request.url.path appaia completamente diverso dal percorso effettivamente richiesto . Il middleware vede un percorso innocuo come /, mentre il router, dietro le quinte, inoltra la richiesta al vero endpoint di destinazione. Qualsiasi middleware di autenticazione basato sul percorso che si fidi di request.url.path può essere aggirato banalmente .

La combinazione perfetta: da 8.7 a 10.0

Il decoratore di autenticazione di LiteLLM controlla request.url.path per determinare se una richiesta necessita di una chiave API valida. Il bypass BadHost permette a un attaccante di manipolare quell'URL in modo che il middleware di autenticazione veda un percorso che non richiede credenziali, mentre il router ASGI smista simultaneamente la richiesta verso uno dei vulnerabili endpoint di command injection MCP .

Questo rimuove l'unico cancello di controllo accessi che si frapponeva tra internet e l'esecuzione di comandi arbitrari. Un attaccante senza credenziali e senza alcun accesso preventivo alla rete può inviare una singola richiesta HTTP creata ad arte, che aggira completamente l'autenticazione ed esegue comandi del sistema operativo sull'host del proxy LiteLLM . Horizon3.ai ha confermato che l'intera catena funziona, assegnandole un punteggio CVSS combinato di 10.0 — massima gravità — proprio perché ottiene l'esecuzione di codice da remoto senza autenticazione .

Cosa possono fare gli attaccanti con questo accesso

Un exploit riuscito fornisce all'attaccante l'esecuzione di comandi con i privilegi del processo proxy LiteLLM. Da lì, la superficie di minaccia si espande rapidamente:

• Esecuzione di comandi arbitrari: Gli attaccanti possono installare backdoor, malware, cryptominer o qualsiasi altro software consentito dai permessi del processo host .
• Furto di credenziali su larga scala: Il proxy LiteLLM si trova tra le applicazioni e decine di fornitori di LLM. Memorizza le chiavi API per OpenAI, Anthropic, Azure, AWS Bedrock, Google e altri servizi connessi nel suo database o in variabili d'ambiente . Sfruttare questa vulnerabilità permette di esfiltrare ogni credenziale memorizzata in una singola operazione.
• Movimento laterale nell'infrastruttura AI: Con le chiavi API cloud rubate e l'accesso shell all'host proxy, gli attaccanti possono rimbalzare verso servizi connessi, server MCP interni, database vettoriali e framework di agenti a valle .
• Implicazioni più ampie per l'ecosistema: La falla BadHost di Starlette colpisce oltre 400.000 progetti dipendenti, incluse applicazioni FastAPI, server vLLM, implementazioni di server MCP e framework per agenti AI. Qualsiasi di questi che utilizzi middleware di autenticazione basato sul percorso su versioni di Starlette precedenti alla 1.0.1 è similmente esposto al bypass di autenticazione .

Perché la mossa del CISA alza il livello di urgenza

L'aggiunta di CVE-2026-42271 al catalogo KEV da parte del CISA l'8 giugno 2026 conferma che la vulnerabilità non è teorica: gli attaccanti la stanno attivamente "militarizzando" in questo momento . In base alla Direttiva Operativa Vincolante 22-01, tutte le agenzie federali civili statunitensi devono applicare le patch per le vulnerabilità elencate nel KEV entro una finestra temporale assegnata. Il CISA raccomanda inoltre vivamente a tutte le organizzazioni, pubbliche e private, di trattare le nuove voci KEV come priorità di patching d'emergenza .

Passi immediati per la correzione

La soluzione per l'exploit concatenato richiede aggiornamenti su due fronti, più diverse misure di difesa in profondità per affrontare l'esposizione delle credenziali:

1. Aggiornare LiteLLM alla versione 1.83.7 o successiva. Questa release rimuove la capacità degli endpoint di test MCP di eseguire direttamente comandi forniti dall'utente, chiudendo completamente il vettore di command injection .
2. Aggiornare Starlette alla versione 1.0.1 o successiva. La patch convalida gli header Host in arrivo rispetto alle specifiche URL e ignora gli header che contengono caratteri non validi, prevenendo il trucco di confusione del percorso che alimenta il bypass di autenticazione .
3. Ruotare immediatamente ogni credenziale memorizzata. Bisogna presumere che qualsiasi chiave API, token di accesso o credenziale di database che il proxy LiteLLM abbia mai memorizzato sia stata compromessa. Ruotare tutte le chiavi di OpenAI, Anthropic, Azure, AWS e altri fornitori, e controllare i pannelli di fatturazione per utilizzi non autorizzati .
4. Bloccare gli endpoint dal reverse proxy o WAF. Come misura di difesa in profondità mentre si distribuiscono le patch, configurare il reverse proxy o il web application firewall per bloccare qualsiasi richiesta a

   POST /mcp-rest/test/connection

   e

   POST /mcp-rest/test/tools/list

   prima che raggiunga l'applicazione .
5. Verificare a posteriori accessi non autorizzati. Controllare i log del proxy LiteLLM per attività insolite sugli endpoint di test MCP, in particolare richieste da indirizzi IP inaspettati o con header Host manipolati .

La gravità CVSS 10.0 combinata, lo sfruttamento attivo in ambienti reali e la designazione KEV del CISA significano che le organizzazioni che utilizzano servizi basati su LiteLLM o Starlette devono trattare questa situazione come un evento di "patch-and-rotate" d'emergenza. La finestra tra lo sfruttamento attivo e l'esfiltrazione delle credenziali è già aperta.