Due falle espongono le chiavi di LiteLLM: la correzione parte dalla 1.83.9

Nella ricerca tecnica del 13 ottobre 2026, Check Point Research descrive due vulnerabilità del gateway LiteLLM, CVE-2026-35029 e CVE-2026-59823, esaminate sulla versione 1.77.7 e corrette entrambe a partire dalla 1.83.9. Un utente autenticato con privilegi limitati poteva modificare la configurazione amministrativa oppure deviare una richiesta verso un server sotto il suo controllo, esponendo una chiave API del provider IA.

Per chi gestisce il proxy, la risposta comincia dall’inventario delle istanze in esecuzione e dall’aggiornamento di quelle interessate. Occorre poi distinguere la correzione del software dall’esame delle attività precedenti: installare la patch impedisce di sfruttare quei percorsi vulnerabili, ma non revoca una credenziale eventualmente già sottratta.

Il controllo dei permessi che apriva la configurazione

CVE-2026-35029 riguardava /config/update, l’endpoint che modifica la configurazione del proxy mentre è in funzione. L’endpoint richiedeva l’autenticazione, ma non controllava esplicitamente che l’utente avesse il ruolo di amministratore. Una sessione creata tramite l’interfaccia di LiteLLM poteva inoltre raggiungerlo perché la regola sulle rotte ammesse trattava il prefisso /config come sufficiente anche per /config/update.

Il risultato era uno scarto fra il ruolo assegnato all’account e le operazioni che l’account poteva compiere. Nei test descritti dai ricercatori, la modifica della configurazione ha permesso di leggere file accessibili al processo LiteLLM, sostituire le credenziali dell’amministratore integrato ed eseguire codice tramite un modulo Python caricato da uno spazio di archiviazione esterno. Sono risultati ottenuti nell’ambiente di prova, non un conteggio di installazioni compromesse.

La lettura dei file sfruttava una variabile usata per indicare il percorso del logo dell’interfaccia: impostandola su un file locale, il contenuto poteva essere restituito da un endpoint del proxy. Per assumere il controllo dell’account amministrativo, invece, bastava cambiare le variabili da cui il login leggeva nome utente e password. La possibilità di registrare un endpoint di passaggio che caricasse codice remoto rendeva il difetto dei permessi rilevante anche per l’integrità del sistema che ospitava il gateway.

La deviazione delle richieste e le chiavi dei provider

CVE-2026-59823 seguiva un percorso distinto: la funzione «Clientside LLM Credentials» accettava user_config nel corpo di una richiesta ai modelli. Tramite quel parametro, un utente autenticato poteva definire un nuovo instradamento e indicare una destinazione scelta da lui. I controlli previsti per parametri di destinazione forniti direttamente nella richiesta non fermavano questo percorso.

LiteLLM si trova fra l’applicazione e il provider del modello e può aggiungere alla richiesta inoltrata le credenziali necessarie per autenticarsi. Nella dimostrazione tecnica, il server scelto dall’attaccante riceveva la richiesta insieme alla chiave del provider presente nelle intestazioni configurate sul proxy. L’esposizione dipendeva dunque dalle credenziali e dalle intestazioni usate dall’istanza coinvolta; una chiave sottratta poteva consentire richieste a carico dell’account dell’organizzazione.

Le tracce da cercare sono diverse da quelle della prima falla. Una modifica inattesa della configurazione può indicare l’abuso dell’endpoint amministrativo; richieste inviate a destinazioni estranee ai provider previsti possono invece aiutare a valutare la deviazione del traffico. Questa distinzione serve anche a circoscrivere quali credenziali erano effettivamente disponibili nel gateway interessato.

Quale versione aggiornare e dove cercare LiteLLM

La soglia comune per le due correzioni è la 1.83.9, ma le patch non sono arrivate insieme. Per CVE-2026-35029, l’avviso GitHub sulla falla dei permessi indica già la 1.83.0 come versione corretta. Un’installazione intermedia può quindi aver chiuso l’accesso improprio alla configurazione senza aver risolto anche la deviazione delle richieste.

Il controllo va fatto sulla versione realmente avviata del proxy, non soltanto su quella dichiarata in un elenco di dipendenze. LiteLLM offre sia una libreria sia un gateway, mentre i percorsi descritti dalla ricerca riguardano il gateway in funzione. Nell’inventario rientrano servizi installati direttamente, istanze incorporate in altri strumenti e copie ancora attive dopo un aggiornamento parziale.

Li Zhao di Black Duck richiama il problema degli usi indiretti nel resoconto di IT Pro: piattaforme, framework e strumenti interni possono includere il gateway senza presentarlo come un servizio autonomo. Per ogni istanza trovata, l’inventario deve collegare la versione in esecuzione agli utenti ammessi, ai ruoli assegnati e ai provider le cui chiavi sono configurate.

Accessi precedenti e rotazione delle credenziali

Dopo l’aggiornamento, la verifica riguarda ciò che un account autenticato avrebbe potuto fare prima della correzione. Gli account con permessi limitati meritano attenzione proprio perché le falle consentivano loro azioni oltre il ruolo previsto. Anche chiavi virtuali, sessioni e account non più necessari vanno confrontati con gli accessi effettivamente autorizzati.

1. Verificare utenti e ruoli. Ricostruire chi poteva accedere a ciascuna istanza vulnerabile e controllare che gli account limitati non possano modificare la configurazione amministrativa dopo l’aggiornamento. Un ruolo registrato correttamente non basta se il comportamento dell’endpoint resta diverso.
2. Esaminare configurazione e richieste. Cercare variazioni inattese delle credenziali amministrative, delle variabili di ambiente e degli endpoint di passaggio. Esaminare separatamente le destinazioni delle richieste ai modelli per individuare eventuali inoltri verso indirizzi non previsti.
3. Valutare le chiavi dei provider. Se emerge un accesso non autorizzato o una richiesta deviata, ruotare le chiavi potenzialmente esposte e controllare l’uso dei relativi account. Quando i registri non permettono di escludere l’esposizione, la rotazione delle chiavi presenti nell’istanza è una misura prudenziale da valutare in base all’accesso che quell’istanza concedeva.

Il punto decisivo è associare ogni possibile esposizione all’istanza e al periodo in cui era vulnerabile. Solo così la revisione degli accessi può individuare le credenziali da sostituire, invece di fermarsi alla conferma che il software ora esegue una versione corretta.

Leggi anche:

• NIH investe 88 milioni nei modelli umani: IA e robot sostituiscono parte dei test
• OAuth con PKCE: un verifier riutilizzato annulla parte della protezione
• GitHub blocca due nuove chiavi Anthropic prima che entrino nel repository