Ricevi DeafLetter
Una selezione settimanale di segnali, vulnerabilità e guide. Gli avvisi critici restano facoltativi.
Puoi cancellarti in ogni momento. Privacy policy.
LiteLLM, gateway open-source per l'orchestrazione di modelli linguistici, presenta vulnerabilità critiche che permettono a qualsiasi utente autenticato — anche con privilegi minimi — di eseguire codice remoto, leggere file arbitrari e impossessarsi dell'account amministratore. Le ricerche di Check Point Research e gli advisory CVE-2026-35029 e GHSA-69x8-hrgq-fjj8 documentano una catena di failure nel controllo degli accessi e nell'hashing delle password che espone l'infrastruttura AI intermedia. La questione non è il modello: è l'architettura che lo sorregge.
- Qualsiasi utente autenticato con ruolo "Internal User" può modificare la configurazione runtime di LiteLLM tramite POST /config/update, assente di qualsiasi verifica RBAC.
- Da questa singola primitiva di accesso si derivano tre tecniche di exploit: arbitrary file read via variabile UI_LOGO_PATH, administrative account takeover via sovrascrittura credenziali, e remote code execution tramite caricamento di moduli Python da storage cloud controllato dall'attaccante.
- CVE-2026-35029 registra un punteggio CVSS 4.0 di 9.9 su scala NVD, con impatto completo su confidenzialità, integrità e disponibilità.
- Parallelamente, GHSA-69x8-hrgq-fjj8 documenta un bypass autenticazione pass-the-hash basato su SHA-256 unsalted, con hash esposti nelle risposte API e accettati come password in /v2/login.
Il fallimento del controllo accessi: da token UI a /config/update
Il meccanismo radicale è una classificazione errata dei token di autenticazione. Secondo Check Point Research, il codice in auth_checks.py etichetta come "ui" qualsiasi token il cui team_id corrisponda a 'litellm-dashboard'. Questa classificazione attiva la funzione _is_ui_route(), che utilizza un matching prefix startswith('/config') per determinare le route accessibili. Il prefisso include /config/update, endpoint che modifica la configurazione runtime del proxy.
La prova tecnica è nel codice di litellm/proxy/proxy_server.py: la funzione update_config invoca user_api_key_auth senza verificare che user_role sia PROXY_ADMIN. Check Point Research confronta esplicitamente questo comportamento con /invitation/new, dove il controllo sul ruolo è presente. La mancanza è sistemica: un utente con privilegi minimi ottiene la stessa capacità operativa dell'amministratore.
L'impatto immediato è la modifica delle variabili d'ambiente. Impostando UI_LOGO_PATH su un percorso arbitrario del filesystem e richiedendo successivamente /get_image, l'attaccante ottiene la lettura di file sensibili. Sovrascrivendo UI_USERNAME e UI_PASSWORD assume il controllo dell'account amministrativo. Registrando endpoint pass-through con moduli Python ospitati su storage cloud controllato, ottiene l'esecuzione remota di codice.
"The most significant issues stemmed from a missing authorization check on the /config/update endpoint, which allowed any authenticated user (including low-privileged accounts) to modify the proxy's runtime configuration. This single flaw enabled arbitrary file read, administrative account takeover, and remote code execution via malicious Python modules loaded from cloud storage."
Il problema crittografico: SHA-256 unsalted e pass-the-hash in tre richieste
Parallelamente alla catena di access control, l'advisory GitHub Security Lab GHSA-69x8-hrgq-fjj8 documenta una debolezza crittografica classica con conseguenze operative severe. Le password utente sono hashate con SHA-256 senza salt. L'hash stesso è esposto nelle risposte di endpoint come /user/info, /user/update e /spend/users.
La conseguenza è un bypass autenticazione di tipo pass-the-hash. L'endpoint /v2/login accetta l'hash raw come password. Un utente autenticato che interroga l'API per ottenere l'hash di un altro utente può immediatamente impersonarlo. Secondo il ricercatore jaydns, autore dell'advisory, l'escalation completa di privilegi richiede tre richieste HTTP.
"An already authenticated user can retrieve another user's password hash from the API and use it to log in as that user. This enables full privilege escalation in three HTTP requests."
Il fix in v1.83.0 migra l'hashing a scrypt con salt casuale di 16 byte, parametri n=16384, r=8, p=1, rimuove gli hash dalle risposte API e implementa una migrazione trasparente al prossimo login. Check Point Research conferma che la versione risolutiva completa per tutte le vulnerabilità documentate, inclusa CVE-2026-35029 e CVE-2026-59823, è la v1.83.9.
Il gateway come punto cieco: pattern ricorrente nell'infrastruttura AI
LiteLLM non è un modello linguistico: è infrastruttura. Finanziato da Y Combinator, funge da proxy unificato per decine di provider LLM. La sua posizione centrale nello stack AI moderno lo rende un target ad alto rendimento.
In analisi: il settore AI infrastructure mostra una tensione strutturale. I gateway LLM moltiplicano i provider gestiti — ogni connessione richiede configurazioni e segreti — ma la maturità dei controlli di sicurezza non tiene il passo. LiteLLM gestisce molteplici credenziali di provider, rendendo il singolo punto di fallimento particolarmente ricco. La velocità di adozione supera quella della revisione sistematica dei controlli accesso.
Il pattern suggerisce un'eco dell'early cloud. Endpoint amministrativi esposti, controlli di accesso insufficienti, hashing password obsoleto: sono errori documentati nella prima generazione di dashboard e API di orchestrazione. La differenza è la velocità di distribuzione corrente. Gli strumenti AI infrastructure vengono integrati oggi con cicli di adozione compressi rispetto ai periodi di consolidamento precedenti.
Cosa fare adesso
L'unica azione documentata nelle fonti è l'aggiornamento a LiteLLM v1.83.9. Check Point Research conferma questa versione come risolutiva per le vulnerabilità analizzate. La fonte non specifica ulteriori passaggi di mitigazione o verifica.
Per la componente pass-the-hash, v1.83.0 introduce la migrazione a scrypt. La fonte non documenta procedure per verificare la completa rimozione di hash SHA-256 pregressi dai sistemi.
La sicurezza dell'AI infrastructure: una domanda aperta
La sicurezza dell'intelligenza artificiale, in questo caso, è fallita a monte. Non nel modello, ma nel gateway che lo rende operativo. La domanda che resta è se l'ecosistema AI infrastructure stia replicando, a velocità multiplicate, gli stessi errori di sicurezza già osservati nelle generazioni precedenti di piattaforme. La risposta determinerà se la prossima ondata di adozione AI sarà costruita su fondamenta più solide — o se il ciclo di scoperta e patch continuerà a ritmo accelerato.
Le informazioni sono state verificate sulle fonti citate e aggiornate al momento della pubblicazione.
Fonti
- https://research.checkpoint.com/2026/when-llm-gateways-go-wrong-findings-from-litellm/
- https://nvd.nist.gov/vuln/detail/cve-2026-35029
- https://github.com/BerriAI/litellm/security/advisories/GHSA-69x8-hrgq-fjj8
Ricevi DeafLetter
Una selezione settimanale di segnali, vulnerabilità e guide. Gli avvisi critici restano facoltativi.
Puoi cancellarti in ogni momento. Privacy policy.