🛡️ Executive Summary
- CVE-2026-35029 permette a un normale utente autenticato di modificare la configurazione runtime di LiteLLM sfruttando un controllo di autorizzazione mancante su
/config/update. - La stessa primitive può essere concatenata per leggere file arbitrari, sostituire le credenziali amministrative e ottenere remote code execution caricando moduli Python attraverso i pass-through endpoint.
- CVE-2026-59823 consente invece SSRF attraverso la funzione Client-side LLM Credentials, con possibile esfiltrazione delle API key dei provider. Le vulnerabilità risultano corrette in LiteLLM 1.83.9.
Un utente LiteLLM già autenticato ma privo di privilegi amministrativi poteva trasformarsi nel controllore dell’intero gateway AI, leggere file locali, sostituire le credenziali dell’amministratore ed eseguire codice sul server. È la catena individuata da Check Point Research analizzando LiteLLM 1.77.7, alla quale si aggiunge una seconda vulnerabilità SSRF capace di dirottare le chiamate ai modelli ed esporre le chiavi API dei provider. Il punto critico non è il modello linguistico e non è una prompt injection: è il control plane che concentra routing, credenziali, configurazioni e accesso a OpenAI, Anthropic, Google o altri backend AI. Matrice Digitale aveva già analizzato LiteLLM come superficie critica dopo precedenti RCE e rischi per le credenziali cloud; la nuova ricerca mostra un delta ancora più insidioso, perché l’attaccante non deve partire dall’esterno senza credenziali. Gli basta essere un utente interno legittimamente autenticato.
Cosa leggere
CVE-2026-35029 rompe il confine tra utente e amministratore
La ricerca originale di Check Point su LiteLLM individua il problema principale nell’endpoint <code>POST /config/update</code>, utilizzato per modificare a runtime impostazioni sensibili del proxy. LiteLLM applicava l’autenticazione generica dell’utente, ma non verificava successivamente che il soggetto possedesse il ruolo PROXY_ADMIN. L’errore veniva aggravato dalla logica usata per le sessioni della dashboard: i token generati dalla UI appartenevano al team speciale <code>litellm-dashboard</code> e venivano classificati come token UI. L’elenco delle route consentite includeva <code>/config</code> e il controllo utilizzava un confronto per prefisso. Di conseguenza anche <code>/config/update</code> iniziava con la stringa autorizzata e superava il filtro.
Il risultato è una classica broken function-level authorization, ma collocata nel punto peggiore possibile. Un Internal User poteva accedere alla funzione pensata per cambiare environment variable, configurazione generale e comportamento del gateway. Non serviva quindi trovare una nuova primitive: bastava abusare delle funzioni amministrative che LiteLLM esponeva già legittimamente. È lo stesso problema architetturale osservato con Bifrost, dove una funzione di management MCP diventava RCE quando la trust boundary amministrativa falliva.
Leggi anche: le vulnerabilità MCP che hanno trasformato framework AI in percorsi verso la remote code execution
Una variabile d’ambiente basta per leggere i file del server
La prima conseguenza documentata da Check Point è la lettura arbitraria dei file accessibili al processo LiteLLM. L’endpoint vulnerabile permette di modificare environment variable che vengono successivamente caricate nell’ambiente del proxy. Tra queste esiste <code>UI_LOGO_PATH</code>, utilizzata dalla dashboard per determinare il file grafico servito dall’endpoint <code>/get_image</code>. Il percorso non veniva limitato a una directory specifica.
Modificando quella variabile, un utente a basso privilegio poteva quindi indurre LiteLLM a restituire un file locale scelto dall’attaccante. Check Point dimostra il problema utilizzando un file di sistema, ma l’impatto reale dipende ovviamente dai privilegi del processo: configurazioni, token, file applicativi e altri segreti leggibili dall’utente che esegue LiteLLM diventano potenzialmente raggiungibili. È una conseguenza particolarmente grave per un gateway che nasce proprio per centralizzare l’accesso a servizi esterni e credenziali AI.
Lo stesso bug permette il takeover dell’account amministratore
La seconda catena sfrutta nuovamente le variabili d’ambiente, questa volta contro il meccanismo di login. LiteLLM può leggere UI_USERNAME e UI_PASSWORD dall’ambiente per autenticare l’amministratore integrato. Poiché CVE-2026-35029 permetteva al normale utente autenticato di modificare quelle stesse variabili attraverso <code>/config/update</code>, l’attaccante poteva sostituire username e password con valori sotto il proprio controllo e autenticarsi successivamente come Proxy Admin.
Il bug assume così una natura diversa da una semplice escalation di privilegi applicativa. L’utente non ottiene soltanto accesso a qualche API aggiuntiva: può prendere il controllo dell’identità amministrativa che governa il gateway. In una piattaforma attraverso cui transitano richieste LLM, budget, routing e credenziali, la compromissione dell’amministratore equivale alla compromissione del punto centrale attraverso cui passa l’infrastruttura AI.
I pass-through endpoint trasformano la configurazione in RCE
La catena più grave porta direttamente alla remote code execution. LiteLLM supporta pass-through endpoint capaci di utilizzare adapter Python caricati anche da storage remoto come S3 o Google Cloud Storage. Quando il target configurato punta a una di queste risorse, il gateway recupera il modulo e lo carica dinamicamente attraverso Python <code>importlib</code>. L’esecuzione del modulo produce anche gli eventuali side effect presenti nel codice al momento dell’importazione. In condizioni normali si tratta di una funzione potente affidata a chi amministra il sistema. Con il bypass di <code>/config/update</code>, però, anche il low-privileged user può definire il modulo remoto da caricare, trasformando una funzione estensibile del gateway in un percorso verso codice arbitrario eseguito con i privilegi del processo LiteLLM. Check Point dimostra la catena con un payload benigno e precisa che lo stesso meccanismo potrebbe essere adattato a furto di credenziali o shell remota. Il problema mostra perché gli strumenti AI siano ormai diventati bersagli autonomi anche nelle competizioni Pwn2Own: gateway e coding agent non sono più semplici frontend per il modello, ma software privilegiato capace di caricare moduli, raggiungere cloud e manipolare segreti.
CVE-2026-59823 ruba le chiavi attraverso una SSRF
Separatamente, Check Point individua CVE-2026-59823 nella funzione Client-side LLM Credentials. LiteLLM permette all’utente autenticato di fornire una configurazione specifica per il routing delle richieste. Attraverso il parametro <code>user_config</code> era possibile impostare un <code>api_base</code> arbitrario e fare in modo che il gateway inviasse la richiesta verso un server controllato dall’attaccante. La conseguenza è una Server-Side Request Forgery, ma con un impatto particolarmente sensibile: la richiesta inoltrata può contenere le credenziali che LiteLLM utilizza per autenticarsi verso il provider LLM. Il server dell’attaccante può quindi ricevere API key che il normale utente del gateway non dovrebbe conoscere. La stessa primitive può inoltre essere utilizzata per raggiungere servizi della rete interna accessibili dal proxy. I controlli già presenti su parametri come <code>api_base</code> e <code>api_key</code> non proteggevano questa strada perché <code>user_config</code> seguiva un percorso differente.
Continua con:
Agenti AI, skill malevole e tool poisoning costruiscono una nuova kill chain
Prompt injection via repository GitHub porta gli agenti AI fino alla reverse shell
LiteLLM 1.83.9 chiude le falle ma il problema è il gateway come concentratore di fiducia
Check Point ha comunicato i risultati attraverso coordinated disclosure e indica le vulnerabilità come risolte a partire da LiteLLM 1.83.9. Alle due CVE principali si aggiungono problemi relativi all’esposizione degli hash delle password e alla loro memorizzazione con un meccanismo privo delle proprietà offerte da funzioni moderne come Argon2, bcrypt o scrypt; questi ultimi risultano ricondotti a un finding già esistente. Per chi gestisce LiteLLM la priorità è quindi aggiornare almeno alla versione corretta, ma le installazioni precedentemente esposte richiedono una valutazione più ampia. Un’istanza sfruttata attraverso queste catene potrebbe avere esposto file locali, account amministrativi, provider key e capacità di esecuzione sul server. Limitarsi ad aggiornare il pacchetto senza considerare rotazione dei segreti e verifica dell’integrità rischia di chiudere la vulnerabilità lasciando valide le credenziali già sottratte. La lezione più importante della ricerca non riguarda però LiteLLM in isolamento. I gateway AI stanno diventando concentratori di fiducia. Ricevono richieste dalle applicazioni, possiedono le credenziali dei modelli, decidono dove instradare il traffico, registrano utilizzo e costi e possono caricare componenti eseguibili. Quando il controllo di autorizzazione fallisce in questo livello, l’attaccante non compromette semplicemente un’altra API: compromette il punto nel quale identità, modelli, cloud e automazione convergono nello stesso control plane.
Iscriviti alla Newsletter
Non perdere le analisi settimanali: Entra nella Matrice Digitale.
Matrice Digitale partecipa al Programma Affiliazione Amazon EU. In qualità di Affiliato Amazon, ricevo un guadagno dagli acquisti idonei. Questo non influenza i prezzi per te.
