Quasi un gateway LiteLLM esposto su dieci accettava la chiave admin predefinita

Quasi un gateway LiteLLM esposto su Internet su dieci accettava la chiave admin di esempio sk-1234 in una scansione di Wiz Research, e quella singola credenziale predefinita apre l'accesso alle chiavi API dei provider memorizzate e, nei test di Wiz, alle credenziali di identità cloud della macchina che esegue il gateway. LiteLLM è un gateway AI open source, il software che un'azienda colloca tra le sue applicazioni e i provider di modelli che paga. La master key è la credenziale di amministratore del gateway, e chiunque la possieda può leggere ogni chiave API dei provider di modelli memorizzata sul server.

Wiz Research ha eseguito una scansione e ha trovato 3.074 gateway LiteLLM su Shodan, un motore di ricerca per sistemi esposti su Internet, a febbraio. Di questi, 294 accettavano sk-1234. In 191 di questi, nessuna chiave era impostata affatto, quindi avrebbero accettato qualsiasi valore, mentre gli altri avevano ancora il valore di esempio della guida di configurazione. Una seconda scansione ad agosto ha individuato più di 85.000 istanze, ma Wiz afferma che la maggior parte sembrano essere honeypot o sistemi di test, quindi i due conteggi non possono essere confrontati e non esiste una cifra attuale. Al 9 settembre, la guida di configurazione di LiteLLM utilizza ancora sk-1234 sopra un commento che dice agli operatori di sostituirla con un valore lungo e casuale prima dell'uso reale.

La ragione per cui una sola chiave conta così tanto è che la master key svolge due funzioni contemporaneamente. È sia la credenziale di amministratore sia l'interruttore che abilita l'autenticazione. Prima della versione 1.82.0-stable, un gateway avviato senza master key concedeva a ogni richiesta in arrivo pieni diritti di amministratore. Un amministratore su uno di questi server ha molto a portata di mano: il gateway può contenere una chiave API per ogni provider a cui instrada, può vedere ogni prompt e risposta che passa, e può connettersi a strumenti interni tramite il Model Context Protocol (MCP), l'interfaccia che consente al gateway di comunicare con i servizi interni. Di solito viene anche eseguito con i permessi cloud del carico di lavoro in cui è distribuito. Le sole chiavi dei provider rubate consentono a un attaccante di eseguire carichi di lavoro dei modelli a spese della vittima, un abuso noto come LLMjacking.

Wiz ha anche mostrato come la chiave possa raggiungere l'account cloud. LiteLLM consente a un amministratore di creare un endpoint pass-through, una rotta che inoltra le richieste a qualsiasi URL scelto dall'amministratore. L'URL di destinazione non viene verificato rispetto a intervalli di indirizzi privati, localhost o indirizzi di metadati cloud. Un amministratore può quindi puntare una rotta al servizio di metadati dell'istanza e rileggere le credenziali IAM che restituisce. Passare a IMDSv2, un modo più recente per richiedere i metadati, non ferma questo. LiteLLM documenta che qualsiasi header inviato con un prefisso x-pass- viene passato alla destinazione con il prefisso rimosso, e Wiz ha usato questo comportamento per inviare gli header richiesti da IMDSv2. Nessuna fonte riporta che qualcuno lo abbia fatto contro una distribuzione reale. È una dimostrazione e richiede prima l'accesso admin. Wiz afferma che la funzionalità funziona probabilmente come previsto perché il modello di minaccia di LiteLLM considera gli amministratori come fidati, quindi non ha CVE né correzione. La politica di sicurezza pubblicata di LiteLLM afferma che gli attacchi che richiedono un errore di configurazione, come non impostare una master key, sono esplicitamente fuori ambito e non trattati come vulnerabilità.

L'unico difetto di esecuzione di codice nel rapporto di Wiz è CVE-2026-59821, e ricercatori e manutentori lo descrivono in modo molto diverso. Wiz lo chiama esecuzione di codice post-autenticazione a livello root e mostra un test che restituisce uid=0(root) all'interno del container del gateway. L'avviso di LiteLLM per lo stesso CVE lo valuta Basso a 2,1 sulla scala CVSS, descrivendo un difetto che richiede un account con privilegi elevati. Entrambi descrivono lo stesso comportamento. Prima della 1.82.0-stable, gli endpoint che creano e aggiornano le guardrail di codice personalizzato saltavano i controlli di sandbox e di pattern applicati dall'endpoint di test, quindi chiunque potesse raggiungerli poteva inviare codice Python che veniva eseguito all'interno del container. L'avviso aggiunge che una distribuzione senza master key trattava i chiamanti come amministratori proxy, il che metteva quegli endpoint a portata di mano. Il rapporto di Wiz afferma che dopo la 1.82.0, un attaccante con la chiave predefinita poteva eseguire codice solo all'interno di una sandbox, ma il registro di LiteLLM non lo supporta per ogni rilascio. Un avviso separato pubblicato a maggio, CVE-2026-40217, afferma che la sandbox poteva essere aggirata usando tecniche di bytecode eseguendo codice nel processo proxy, il programma principale che gestisce il traffico, che l'avviso nota essere eseguito come root nell'immagine Docker predefinita. Copre le versioni dalla 1.81.8 fino alla 1.83.10 esclusa, e raggiungere l'endpoint richiede una credenziale di amministratore proxy, che è la master key. Entrambi i difetti segnalati da Wiz sono stati corretti mesi prima del suo rapporto del 9 settembre, a febbraio e aprile, e i loro CVE sono stati pubblicati a luglio.

Separatamente, problemi più vecchi di LiteLLM sono già sfruttati. CISA ha aggiunto CVE-2026-59822 al suo catalogo delle vulnerabilità note sfruttate il 2 settembre. Il difetto, anch'esso trovato da Wiz, ha un punteggio CVSS di 8,8 e consente a un attaccante non autenticato di aprire una sessione MCP valida usando qualsiasi token Bearer, incluso uno lungo un solo carattere. Le agenzie civili federali hanno tempo fino al 16 settembre per affrontarlo. Wiz lo ha visto usato contro i propri honeypot a partire dal 7 luglio, in richieste che portavano token di un solo carattere per sondare gli endpoint di elenco dei modelli, e non ha descritto altri usi. Quel difetto non raggiunge i percorsi di esecuzione di codice o di credenziali di cui sopra. Wiz afferma che consente solo l'accesso al server MCP, e ciò che può raggiungere dipende da quali server di strumenti un'organizzazione ha connesso.

Il difetto di LiteLLM che gli attaccanti hanno usato per eseguire codice è un altro. CVE-2026-42271 ha un punteggio CVSS di 8,7 e consentiva a qualsiasi utente autenticato di eseguire comandi sull'host attraverso due endpoint di test MCP. Horizon3.ai ha riferito a giugno che poteva essere concatenato con un difetto host-header di Starlette, CVE-2026-48710, per fare lo stesso senza alcuna credenziale. Gli honeypot di Wiz hanno registrato che quel difetto veniva usato per installare un miner di criptovalute. Microsoft ha pubblicato ad agosto un caso in cui gli attaccanti eseguivano comandi all'interno di un processo gateway LiteLLM, leggevano l'ambiente del container per la master key, le chiavi dei provider e la stringa di connessione al database, e poi usavano quella stringa per accedere al server di database relazionale sottostante e copiare record dalle tabelle dei modelli e delle chiavi virtuali di LiteLLM. Microsoft valuta con alta confidenza che gli attaccanti hanno ottenuto l'accesso attraverso il gateway esposto e afferma che il punto di ingresso corrisponde alla catena CVE-2026-42271 e CVE-2026-48710. L'azienda ha aggiunto: "Trattate i gateway AI come archivi di segreti di livello Tier-0".

L'aggiornamento a LiteLLM 1.84.0 o successivo copre ogni difetto nella tabella. CVE-2026-59822 è corretto nella 1.84.0. CVE-2026-42271 è corretto nella 1.83.7. CVE-2026-59821 è corretto nella 1.82.0-stable. CVE-2026-40217 è corretto nella 1.83.10, anche se il testo dell'avviso di LiteLLM indica la 1.83.11. Il primo passo pratico è cambiare la master key da sk-1234 a un valore lungo e casuale. Questo non richiede aggiornamenti e chiude ogni percorso nel rapporto di Wiz che dipende dal possesso della chiave. Prima di ruotare la chiave, verificate se è impostata una salt key separata, perché la procedura di rotazione è diversa e usarne una sbagliata può rendere illeggibili le credenziali memorizzate. Se non potete ancora aggiornare, bloccate /mcp/ e i due endpoint di test MCP, POST /mcp-rest/test/connection e POST /mcp-rest/test/tools/list, sul vostro reverse proxy o gateway API. Bloccate anche POST /guardrails/test_custom_code e limitate POST /guardrails e PUT /guardrails/{guardrail_id} agli amministratori. Queste sono le soluzioni alternative negli avvisi di LiteLLM stesso. Esaminate gli endpoint pass-through sul gateway, limitate l'accesso di rete in uscita del container e assegnate al carico di lavoro il ruolo IAM cloud più ristretto possibile. Se pensate che un attaccante possa aver avuto accesso, controllate l'elenco delle guardrail per voci che non avete creato e riavviate il processo per cancellare il codice tenuto in memoria, poi ruotate le chiavi dei provider, la master key e le credenziali del database. L'aggiornamento non rimuove né una guardrail registrata da un attaccante né una chiave SSH che hanno aggiunto.

Non esiste una patch per la rotta pass-through verso i metadati dell'istanza perché LiteLLM non la considera un difetto. I limiti di rete in uscita e i ruoli IAM ristretti sono gli unici controlli disponibili. Nessuna fonte spiega come verificare se le rotte MCP o pass-through sono abilitate su un gateway che avete ereditato. Le query di caccia di Microsoft trovano lo sfruttamento, non la configurazione. Per i proprietari di siti web e i team IT che gestiscono servizi come questo nella propria infrastruttura, AEU-I offre IT, infrastruttura e consulenza orientati alla sicurezza per aiutare a rivedere i gateway esposti e mantenere i permessi cloud il più ristretti possibile.