Ricevi DeafLetter
Una selezione settimanale di segnali, vulnerabilità e guide. Gli avvisi critici restano facoltativi.
Puoi cancellarti in ogni momento. Privacy policy.
Il 9 settembre 2026, la ricerca di Wiz rende pubblica una campagna di scansione su 3.074 istanze LiteLLM esposte a Internet: il 9,6% accetta la chiave master di default "sk-1234" o nessuna autenticazione, rendendo praticabile un attacco pre-autenticazione che passa dal bypass MCP all'esecuzione di codice remota con privilegi di root. CVE-2026-59822, il bypass dell'autenticazione per il protocollo Model Context Protocol, è già nel catalogo CISA Known Exploited Vulnerabilities con exploit confermato in-the-wild.
- CVE-2026-59822: bypass MCP con qualsiasi token Bearer arbitrario, inclusa una stringa come "a"
- CVE-2026-59821: RCE root-level via custom code guardrails con exec(compile(...)) senza restrizioni
- Il 9,6% di 3.074 istanze pubbliche (295) accetta chiave di default o nessuna autenticazione
- CISA KEV conferma exploitation in-the-wild tramite honeypot Wiz
"Nearly 1 in 10 publicly accessible LiteLLM instances accept a default master key or require no authentication at all"
Il meccanismo del bypass MCP: quando un 401 diventa sessione valida
Il protocollo Model Context Protocol (MCP), sviluppato da Anthropic e adottato da LiteLLM per estendere i gateway LLM a tool esterni, richiede autenticazione tramite token Bearer. Secondo la ricerca di Wiz, il file user_api_key_auth_mcp.py gestisce la validazione con una logica difettosa: qualsiasi token arbitrario, anche una stringa come "a", genera un errore 401 che il handler cattura e trasforma in un oggetto di autenticazione vuoto ma valido.
L'effetto è immediato. L'attaccante ottiene una sessione autenticata senza possedere credenziali valide, con accesso ai tool MCP connessi: database, repository GitHub, filesystem locali, pipeline CI/CD. Il dato emerge dalla scansione reale di istanze pubbliche, non da analisi teorica del codice. La fonte non specifica quante di queste istanze abbia attivamente esposto tool MCP sensibili, ma la superficie d'attacco è strutturale.
"Any garbage token fails validation with a 401, and the handler proceeds as if nothing happened"
Dal bypass all'esecuzione: come la chiave di default abilita RCE root-level
La seconda vulnerabilità, CVE-2026-59821, risiede nel modulo custom code guardrails di LiteLLM. La funzione _compile_custom_code() in custom_code_guardrail.py esegue exec(compile(...)) sul codice fornito dall'utente senza strip di __builtins__ e senza forbidden patterns check. Il risultato è RCE con privilegi di root al momento della registrazione del guardrail.
La ricerca documenta che l'esecuzione avviene durante l'inizializzazione, non al momento dell'invocazione successiva. "The code executes immediately when the guardrail is registered, since the import os and os.popen('id') run during initialization". Questo timing elimina ogni finestra di rilevamento basata sul comportamento dell'utente finale.
La combinazione con CVE-2026-59822 e con le configurazioni insecure amplifica il rischio. Quando l'autenticazione non è configurata, LiteLLM assegna automaticamente il ruolo PROXY_ADMIN a tutti gli utenti. Non è richiesta CVE dedicata: la condizione è stata corretta contestualmente a CVE-2026-59821. Con PROXY_ADMIN e chiave di default, l'attaccante non ha bisogno di compromettere account esistenti.
Un terzo degli ambienti cloud: la portata del gateway compromesso
LiteLLM funge da gateway per oltre 100 provider LLM. Secondo i dati Wiz, è presente in circa un terzo degli ambienti cloud monitorati dalla piattaforma. Questa ubiquità trasforma una vulnerabilità di prodotto in un problema di perimetro infrastrutturale: il gateway LLM non è più un semplice proxy API, ma un execution environment con superficie d'attacco estesa.
Il pass-through endpoint aggiunge un vettore complementare. La mancanza di URL validation permette il furto di credenziali cloud post-autenticazione, effettivamente pre-autenticazione quando la chiave di default o l'assenza di autenticazione sono presenti. Il dossier non specifica quali provider cloud siano maggiormente interessati da questo canale di esfiltrazione.
La ricerca è stata presentata a DEF CON 34. Tutte le vulnerabilità identificate sono state patchate dopo responsible disclosure. La fonte non dettaglia versioni specifiche vulnerabili oltre alla formula "prima del fix".
Cosa fare adesso
Gli operatori che gestiscono istanze LiteLLM devono verificare immediatamente la configurazione dell'autenticazione MCP. La scansione Wiz indica che il 9,6% delle istanze pubbliche è esposto: chiunque utilizzi LiteLLM in produzione deve confermare che la chiave master di default "sk-1234" sia stata sostituita e che l'autenticazione sia obbligatoria, non opzionale.
Per il modulo custom code guardrails, è necessario verificare che l'istanza esegua la versione patchata. La funzione _compile_custom_code() nelle versioni vulnerabili esegue exec() senza isolamento: l'aggiornamento alla versione corretta introduce i controlli mancanti su __builtins__ e sui pattern vietati.
La presenza di LiteLLM in circa un terzo degli ambienti cloud richiede un inventario accurato delle installazioni. Le istanze interne non esposte direttamente a Internet restano vulnerabili se accessibili da reti laterali compromesse. L'inclusione di CVE-2026-59822 nel catalogo CISA KEV impone priorità di remediation elevata per gli enti federali e raccomanda urgenza per il settore privato.
Domande e risposte
Cosa rende CVE-2026-59822 "pre-autenticazione" se richiede un token Bearer?
Il token può essere arbitrario: la validazione fallisce con 401, ma il handler genera comunque una sessione autenticata. Qualsiasi stringa funziona, quindi non è richiesta conoscenza di credenziali valide né compromissione preliminare.
Perché la RCE è "root-level" e non limitata all'utente del servizio?
Il codice del guardrail viene eseguito tramite exec() con __builtins__ intatto. La fonte documenta l'esecuzione di os.popen('id') con privilegi elevati, indicando che il processo LiteLLM gira con permessi di root.
Il fix è disponibile, ma chi è effettivamente aggiornato?
La scansione di 3.074 istanze mostra che il 9,6% mantiene configurazioni insecure. Il dato non distingue tra istanze non aggiornate e istanze aggiornate ma riconfigurate con chiavi deboli. La fonte non fornisce trend temporale di adozione delle patch.
Le informazioni sono basate sulla fonte citata e aggiornate al momento della pubblicazione.
Fonti
Ricevi DeafLetter
Una selezione settimanale di segnali, vulnerabilità e guide. Gli avvisi critici restano facoltativi.
Puoi cancellarti in ogni momento. Privacy policy.