LiteLLM espone un gateway AI su dieci: RCE root e furto IAM dietro chiavi predefinite

🛡️ Executive Summary

• Wiz ha analizzato 3.074 istanze LiteLLM esposte e ha trovato il 9,6% con master key predefinita o completamente prive di autenticazione.
• CVE-2026-59822 consente di creare una sessione MCP autenticata con un Bearer token arbitrario ed è già stata sfruttata in-the-wild.
• Una seconda falla nei custom guardrail può portare a esecuzione Python come root, mentre i pass-through endpoint possono essere abusati per sottrarre credenziali IAM cloud.

Quasi un gateway LiteLLM pubblico su dieci analizzato da Wiz accetta ancora la master key predefinita oppure non applica alcuna autenticazione, trasformando quello che dovrebbe essere il punto centrale di controllo dell’infrastruttura AI in un possibile trampolino verso modelli, server MCP e ambiente cloud. La ricerca individua una catena che parte da CVE-2026-59822, authentication bypass sull’endpoint MCP già sfruttato in-the-wild, e arriva fino a esecuzione di codice root attraverso CVE-2026-59821 nelle versioni vulnerabili. Anche senza una nuova vulnerabilità, una configurazione debole può inoltre consentire di raggiungere le API dei provider LLM o abusare dei pass-through endpoint per interrogare i metadata service cloud e sottrarre credenziali IAM.

Il 9,6% delle istanze pubbliche accetta sk-1234 o nessuna chiave

La ricerca pubblicata da Wiz sul perimetro LiteLLM parte da una scansione di 3.074 proxy pubblicamente raggiungibili condotta nel febbraio 2026. Di questi, 294 — il 9,6% — accettavano la master key predefinita sk-1234 oppure non richiedevano autenticazione. All’interno dello stesso campione, 191 istanze, pari al 6,2%, risultavano completamente aperte. Il dato è particolarmente rilevante perché LiteLLM non è un semplice frontend per interrogare un modello. Il gateway offre un’unica API compatibile OpenAI verso oltre cento provider, può conservare chiavi per OpenAI, Anthropic, AWS Bedrock, Azure e Vertex AI, gestire budget, applicare guardrail e collegare strumenti attraverso MCP. Wiz stima inoltre che LiteLLM sia presente in circa un terzo degli ambienti cloud osservati dalla propria telemetria.

Matrice Digitale aveva già analizzato LiteLLM come superficie critica dopo SQL injection, command injection e ingresso nel catalogo KEV. La nuova ricerca aggiunge un elemento operativo: una vulnerabilità grave diventa molto più semplice da sfruttare quando l’infrastruttura continua a essere installata con credenziali d’esempio.

Un Bearer token qualsiasi apre una sessione MCP

CVE-2026-59822 riguarda il percorso di autenticazione specifico dell’endpoint MCP. LiteLLM deve distinguere tra chiavi interne e token OAuth destinati ai server MCP upstream, ma la logica vulnerabile gestiva in modo errato il fallimento della validazione. Quando un Bearer token riceveva 401 o 403, il codice poteva restituire un oggetto di autenticazione vuoto e proseguire come se la richiesta fosse valida. Il risultato era estremamente semplice: anche un token arbitrario poteva produrre una sessione MCP valida. Una volta dentro, l’impatto dipende dai server collegati. Se LiteLLM espone strumenti per database, GitHub, file system, Jira, Slack o pipeline CI/CD, l’attaccante può utilizzare le operazioni consentite a quella sessione e passarvi parametri controllati. Wiz ha osservato CVE-2026-59822 sfruttata nella propria infrastruttura honeypot il 7 luglio. La vulnerabilità è stata corretta nella versione 1.84.0 e il 2 settembre CISA l’ha inserita nel catalogo Known Exploited Vulnerabilities. La dinamica conferma quanto già emerso nelle campagne che prendono di mira server MCP e gateway AI direttamente esposti su Internet.

Leggi anche: vCenter sotto attacco e LiteLLM compromesso mostrano come le piattaforme di gestione diventino moltiplicatori d’accesso

I custom guardrail possono diventare codice Python eseguito come root

Una seconda vulnerabilità, CVE-2026-59821, riguarda i custom code guardrail. LiteLLM permette agli amministratori di scrivere codice Python-like da eseguire prima o dopo una richiesta al modello, utile per bloccare prompt sensibili o applicare policy personalizzate. Il problema individuato da Wiz è che il percorso utilizzato per registrare un nuovo guardrail non applicava le stesse protezioni usate dalla funzione di test. Il test eliminava i built-in Python e bloccava pattern come import, exec, eval, os e subprocess. L’endpoint di registrazione, invece, compilava ed eseguiva il codice senza applicare correttamente quei controlli. In un ambiente vulnerabile, codice controllato dall’utente poteva quindi essere eseguito attraverso exec() con accesso alla libreria standard Python. Nei test Wiz l’esecuzione avveniva con UID 0, quindi root all’interno del container LiteLLM. La falla è stata corretta dalla versione 1.82.0 e i guardrail sono ora protetti da controlli PROXY_ADMIN e sandbox coerente. Questa vulnerabilità non può essere concatenata direttamente al solo bypass MCP, perché quest’ultimo concede l’accesso al protocollo MCP e non all’intero pannello amministrativo. La catena diventa però sostanzialmente pre-auth quando l’istanza usa ancora la master key predefinita o non configura autenticazione.

Senza master key ogni utente diventava amministratore

Wiz ha individuato un secondo problema di configurazione particolarmente pericoloso. Nelle versioni precedenti alla correzione, se LiteLLM veniva avviato senza master key, OAuth o JWT, il sistema non si limitava ad accettare richieste anonime: assegnava automaticamente il ruolo PROXY_ADMIN. La configurazione priva di autenticazione trasformava quindi qualsiasi utente in amministratore del gateway. Il comportamento è stato modificato, attribuendo il ruolo meno privilegiato INTERNAL_USER e introducendo controlli amministrativi sugli endpoint più sensibili. Il problema mostra perché la master key non può essere trattata come una semplice API key. LiteLLM la utilizza sia come credenziale amministrativa sia come segreto HS256 per firmare sessioni JWT. Se rimane sk-1234, un attaccante può forgiare sessioni valide e controllare una parte significativa della piattaforma.

Il pass-through può raggiungere AWS metadata e sottrarre IAM

La catena non si ferma al gateway AI. LiteLLM dispone di pass-through endpoint capaci di inoltrare richieste verso URL configurabili. Wiz evidenzia che il target non viene validato contro indirizzi privati, localhost o cloud metadata service. Un amministratore compromesso può quindi configurare un endpoint diretto verso 169.254.169.254 e interrogare il metadata service di AWS per recuperare AccessKeyId, SecretAccessKey e token temporanei IAM associati all’istanza. La tecnica funziona anche contro IMDSv2 perché LiteLLM può inoltrare header arbitrari al server target. Wiz precisa correttamente che questo comportamento non è considerato di per sé una vulnerabilità: un amministratore è già un soggetto trusted. Il problema nasce quando quel ruolo viene ottenuto grazie a una chiave predefinita, all’assenza di autenticazione o a una falla precedente. È proprio qui che il rischio diventa cloud-wide. Un gateway LiteLLM può avere permessi per Bedrock, Vertex AI, secret manager e altri servizi interni. Compromettere il proxy significa quindi ottenere un punto di partenza per movimento laterale oltre la stessa infrastruttura AI.

Continua con:

• LiteLLM ha già subito una compromissione della supply chain capace di sottrarre segreti cloud e Kubernetes
• AWS corregge nuovi bypass read-only nei server MCP PostgreSQL e MySQL

I gateway AI non sono più strumenti da sviluppatori

La conclusione più importante della ricerca Wiz riguarda il modello di sicurezza, non la singola CVE. Un gateway AI possiede ormai le caratteristiche di un asset Tier-1: concentra credenziali, intercetta prompt e risposte, esegue codice server-side, parla con strumenti MCP e spesso opera con ruoli cloud privilegiati. Trattarlo come un proxy sperimentale protetto da una sola shared secret significa ignorare il valore che possiede per un attaccante. La remediation parte dall’aggiornamento di LiteLLM alle versioni corrette, ma non può fermarsi lì. Serve eliminare immediatamente sk-1234, utilizzare una master key forte e unica, controllare guardrail e pass-through endpoint, limitare l’egress del container e soprattutto applicare least privilege ai ruoli IAM.

Perché il problema evidenziato da Wiz è ormai strutturale: l’infrastruttura costruita per centralizzare l’AI sta centralizzando anche le possibilità di comprometterla.