Wiz: quasi 1 gateway LiteLLM esposto su 10 accetta la chiave admin di esempio sk-1234

Il 9 settembre 2026 Wiz Research ha pubblicato uno studio su LiteLLM, il gateway AI open source che si colloca tra le applicazioni e i fornitori di modelli a cui queste pagano, e ha riportato che 294 delle 3.074 distribuzioni di LiteLLM che riusciva a raggiungere su internet pubblico — il 9,6%, quasi una su dieci — accettavano sk-1234, la chiave master di esempio riportata nella documentazione di configurazione del progetto stesso, oppure non richiedevano alcuna credenziale. Quella stringa non è una normale chiave API: in LiteLLM è sia la credenziale di amministratore sia l'interruttore che attiva l'autenticazione, quindi chiunque la presenti può leggere ogni chiave dei provider di modelli memorizzata sul gateway, osservare ogni prompt e completion che vi transitano e raggiungere ogni server di strumenti connesso tramite il Model Context Protocol. I coautori di Wiz, Amitai Cohen e Yaara Shriki, hanno concatenato quell'accesso all'esecuzione di codice a livello root e al furto delle credenziali IAM cloud dell'host. Questo resoconto si basa sul rapporto di Wiz, sugli avvisi di sicurezza di LiteLLM stesso e sull'elenco CISA Known Exploited Vulnerabilities che ne è seguito, e l'archivio degli incidenti AI conserva questa voce accanto alle sue vicine, ciascuna con le proprie fonti, il proprio livello di gravità e di confidenza.

La data di pubblicazione è l'unica data riportata nel documento, ed è una data di pubblicazione. La scansione alla base del titolo è stata eseguita a febbraio 2026; le due falle nel codice descritte da Wiz avevano già ricevuto correzioni al più tardi a metà maggio, in versioni che i registri del progetto stesso datano a marzo e maggio; gli identificativi CVE sono stati assegnati a luglio; e la scheda nel catalogo è arrivata a settembre. Quasi tutto nel rapporto era già vecchio nel momento in cui è stato stampato, il che è in gran parte ciò che il rapporto sostiene.

Il 9,6% si riferisce a una singola scansione, e Wiz afferma che il proprio follow-up di agosto non è confrontabile con essa.

La misurazione è semplice e Wiz dichiara chiaramente il proprio metodo: 3.074 proxy LiteLLM esposti su Internet trovati tramite Shodan a febbraio 2026, ciascuno testato per verificare se si sarebbe autenticato con la chiave di esempio documentata. Di questi, 294 lo hanno fatto. All'interno di quel gruppo, 191 non avevano alcuna master key configurata e avrebbero accettato qualsiasi stringa fosse stata loro proposta; gli altri avevano lasciato al suo posto il segnaposto della guida alla configurazione. Nessuna delle due modalità di errore richiede un bug software. Entrambe necessitano solo dell'indirizzo del gateway e del valore stampato nel README del progetto stesso.

Si tratta inoltre della scansione di un singolo fornitore. La cifra di Wiz è stata ripetuta dall'AI Safety Initiative della Cloud Security Alliance il 10 settembre e da The Hacker News lo stesso giorno, ma entrambi la riportano citandone la fonte, e per questo articolo non è stata trovata alcuna replica indipendente del dato di 3.074. Wiz ha eseguito una seconda scansione in agosto 2026 e ha trovato più di 85.000 istanze, circa ventisette volte il conteggio di febbraio. L'azienda afferma che la maggior parte di queste sembrano essere honeypot o distribuzioni di test, e che i due conteggi non possono essere confrontati. Non esiste un dato attuale sull'esposizione, e qualsiasi articolo che ne citi uno sta citando febbraio.

Un altro dato nel report non proviene da una scansione, ma dalla telemetria di Wiz stessa: l'azienda afferma che LiteLLM è presente in circa un terzo degli ambienti cloud che osserva. Si tratta della visione di un fornitore sulla propria base di clienti e va quindi presa con le dovute cautele, ma spiega perché i ricercatori abbiano trattato una configurazione errata del gateway come un problema cloud anziché applicativo.

La chiave principale è sia la credenziale di amministratore sia l'interruttore che attiva l'autenticazione

Il design di LiteLLM assegna due compiti a un unico segreto. La master key autentica le richieste amministrative, ed è la sua presenza a rendere possibile l'autenticazione: senza master key e senza configurazione JWT o OAuth2, il proxy viene eseguito aperto e accetta ogni richiesta. Wiz ha esaminato la base di codice con Claude Code di Anthropic, cercando funzionalità che ricevono input controllati dall'utente e li passano a un contesto di esecuzione, e il gestore dell'autenticazione è stata una delle tre superfici segnalate.

Prima della v1.82.0-stable la conseguenza di quel secondo job era peggiore di un proxy aperto. Wiz ha scoperto che, quando non era impostata alcuna master key, l'handler di autenticazione assegnava il ruolo PROXY_ADMIN a ogni richiesta in ingresso, quindi un chiamante non autenticato non veniva semplicemente ammesso, ma ammesso come amministratore. La pull request #22095, citata nel rapporto, ha cambiato il ruolo predefinito in INTERNAL_USER e aggiunto un controllo admin agli endpoint di guardrail.

L'accesso amministrativo a un gateway non è un privilegio ristretto. L'istanza detiene una chiave API per ogni provider verso cui instrada, ed è questo che la rende un bersaglio per il LLMjacking: eseguire carichi di lavoro dei modelli a spese della vittima. Vede i prompt e le completions. Si connette verso l'esterno a server di strumenti MCP, che in un deployment interno è probabile includano sistemi di tracciamento delle issue, chat, database e pipeline di deployment.

Wiz ha inoltre dimostrato un percorso da quella posizione amministrativa all'identità cloud dell'host. LiteLLM consente a un amministratore di registrare una route pass-through verso qualsiasi URL di destinazione, e la destinazione non viene verificata rispetto a intervalli di indirizzi privati, localhost o all'indirizzo dei metadati cloud. Puntare una route al servizio di metadati dell'istanza restituisce le credenziali IAM con cui viene eseguito il workload. Passare il servizio di metadati a IMDSv2, che normalmente sconfigge questa classe di request forgery richiedendo un token di sessione ottenuto separatamente, non aiuta: LiteLLM inoltra alla destinazione qualsiasi header con prefisso x-pass- rimuovendo il prefisso, così l'header del token può essere fatto passare di nascosto. Wiz afferma che la funzionalità, con ogni probabilità, funziona come previsto secondo un modello di minaccia che considera affidabili gli amministratori, e che quindi non ha né un CVE né una correzione.

L'ultimo paragrafo è una dimostrazione, non un attacco osservato. The Hacker News, nel riportare la ricerca il 10 settembre, afferma che nessuna fonte segnala che qualcuno lo abbia fatto contro un deployment reale e che richiede prima l'accesso amministrativo. La formulazione di Wiz è la stessa: il pass-through è una proprietà di progettazione che diventa una vulnerabilità solo quando la credenziale dell'amministratore è una stringa presa dalla documentazione.

8.8 e 2.1 valutano la stessa catena da posizioni di partenza diverse

Due CVE racchiudono i risultati tecnici, e i loro punteggi pubblicati difficilmente potrebbero essere più distanti.

CVE-2026-59822 è il bypass dell'autenticazione MCP, e l'advisor di LiteLLM lo classifica come Alto, 8.8 secondo CVSS 4.0, senza privilegi richiesti, senza interazione dell'utente e senza requisiti di attacco. L'endpoint MCP dispone di un proprio gestore di autenticazione, progettato per accettare una chiave LiteLLM oppure un token OAuth2 destinato a un server di strumenti upstream. Quando un token non superava la validazione di LiteLLM, il gestore intercettava il 401 e sostituiva un oggetto di autenticazione vuoto invece di rifiutare la richiesta. Qualsiasi token Bearer produceva quindi una sessione MCP valida, persino un singolo carattere: la proof of concept di Wiz invia un token bearer di una sola lettera e riceve indietro un identificatore di sessione. La vulnerabilità è corretta nella versione 1.84.0.

CVE-2026-59821 è la falla del guardrail, e l'avviso dello stesso progetto la classifica come Bassa, 2.1, con privilegi elevati richiesti e requisiti di attacco presenti. La funzionalità di guardrail con codice personalizzato consente a un amministratore di inviare codice Python che il server compila ed esegue. L'endpoint di test della Web UI convalidava il codice rispetto a un elenco di pattern vietati e rimuoveva i builtin prima di eseguirlo; gli endpoint di creazione e aggiornamento in produzione non facevano né l'uno né l'altro. Python ripopola i builtin quando sono assenti, quindi il codice inviato raggiungeva la libreria standard. Il proof of concept di Wiz registra un guardrail che esegue un comando shell al momento della registrazione — prima di qualsiasi richiesta al modello — e restituisce l'output del comando come motivo del blocco, che nel suo test è risultato root. La falla è corretta in v1.82.0-stable.

Le due descrizioni sono compatibili, e la frase che le concilia è contenuta nell'advisory stesso: LiteLLM osserva che nelle distribuzioni prive di una chiave master configurata i chiamanti potrebbero essere trattati come amministratori del proxy, ed è questo che ha messo gli endpoint di guardrail alla portata. A 2.1 presuppone un utente privilegiato. La catena di Wiz è ciò che accade quando la chiave predefinita rende privilegiato ogni chiamante. Nessuno dei due punteggi sbaglia riguardo alla propria posizione di partenza; dissentono su quanto spesso quella posizione sia libera.

Una riserva riguarda l'affermazione di Wiz secondo cui, dopo la 1.82.0, un attaccante in possesso della chiave predefinita avrebbe potuto eseguire codice solo all'interno di una sandbox. The Hacker News rimanda a un avviso separato di maggio 2026, CVE-2026-40217, che descrive la possibilità di uscire da quella sandbox tramite tecniche di bytecode nelle versioni dalla 1.81.8 fino alla 1.83.10 esclusa, all'interno di un processo proxy che, secondo l'avviso, viene eseguito come root nell'immagine container predefinita. Per raggiungere quell'endpoint serve una credenziale di amministratore del proxy, che è esattamente ciò che è la chiave master.

Neanche l'8.8 è universale. La nota di ricerca della Cloud Security Alliance osserva che l'avviso di GitLab indica un punteggio di base di 8.2 per la stessa vulnerabilità e si astiene dal pronunciarsi tra le due metodologie, limitandosi a rilevare che entrambe si collocano nella fascia alta. La gravità alta del record non dipende da quale numero venga usato.

Una CVE è stata sfruttata in natura; l'esposizione della chiave predefinita non ha una vittima nominata.

Il CISA ha aggiunto CVE-2026-59822 al catalogo delle vulnerabilità note come sfruttate il 2 settembre 2026 e ha fissato al 16 settembre 2026 la scadenza per la correzione da parte delle agenzie civili federali; la voce del catalogo riporta CWE-287 e CWE-306, ossia autenticazione impropria e autenticazione mancante. La nota della Cloud Security Alliance riferisce che i monitoraggi di settore l'hanno descritta come la prima vulnerabilità specifica di MCP presente in tale elenco. Wiz ha pubblicato lo sfruttamento osservato: dal 7 luglio 2026 i suoi honeypot hanno registrato richieste contenenti token bearer di un solo carattere che sondavano endpoint di elenco dei modelli, e Wiz non descrive alcun altro uso della vulnerabilità.

Non esiste nulla di comparabile per la chiave predefinita. Nessuna vittima viene nominata, nessun gateway viene identificato come compromesso tramite sk-1234 e nessuna telemetria mostra i 294 host in uso. La voce dell'archivio non registra alcun danno reale, il che è un'affermazione sulle prove anziché sul meccanismo: l'esposizione è stata misurata, non osservata mentre veniva sfruttata.

Altri due elementi vengono spesso archiviati insieme a questi e non sono la stessa cosa. CVE-2026-42271, esecuzione di comandi tramite due endpoint di test MCP, è la vulnerabilità di LiteLLM che gli attaccanti hanno effettivamente usato per eseguire codice; gli honeypot di Wiz hanno registrato che installava un miner di criptovalute. Il caso dell'agosto 2026 pubblicato da Microsoft, in cui un intruso ha letto le variabili d'ambiente di un container gateway, recuperato la chiave master, le chiavi dei provider e una stringa di connessione al database, quindi copiato record dalle tabelle dei modelli e delle chiavi virtuali di LiteLLM, illustra quanto vale un gateway compromesso piuttosto che un nuovo modo per entrare; The Hacker News riporta che Microsoft valuta il punto di ingresso come la catena CVE-2026-42271.

La posizione dei manutentori è che una chiave master mancante sia un errore di configurazione, non una vulnerabilità.

La politica di sicurezza di LiteLLM è esplicita. Tra i problemi fuori ambito elenca "attacchi che richiedono una configurazione errata in fase di installazione (ad esempio non impostare una master_key nella configurazione del proxy)", e afferma che questi sono esplicitamente fuori ambito e non sono considerati vulnerabili. Wiz giunge a una conclusione compatibile dalla direzione opposta quando definisce il comportamento di pass-through probabilmente funzionante come previsto.

Quella posizione è stata messa alla prova pubblicamente. Il 15 agosto 2026 un ricercatore ha aperto la issue GitHub #37054, segnalando che un proxy con LITELLM_MASTER_KEY non impostata autentica qualsiasi valore di chiave e che il file docker-compose fornito non ne imposta una. La issue è stata chiusa 30 minuti dopo, e l'unico commento presente proviene dallo stesso account: cita l'indicazione della policy di sicurezza secondo cui le segnalazioni devono passare tramite segnalazioni private di vulnerabilità anziché issue pubbliche, si scusa per aver presentato la segnalazione pubblicamente e afferma che il rapporto completo è stato invece inviato tramite il canale degli advisory. Nel thread non compare alcuna risposta dei maintainer, pertanto la documentazione mostra il reporter che ritira la segnalazione pubblica, anziché una risposta del progetto alla stessa. Nulla di pubblico documenta che fine abbia fatto la segnalazione privata.

Nessuna dichiarazione pubblica di BerriAI a difesa o a revisione di tale posizione sul rapporto di settembre è stata reperita per questo articolo. La risposta visibile dell'azienda si trova nelle sue note di rilascio e nei suoi file di configurazione anziché in prosa.

L'esecuzione è arrivata il 3 ottobre, ventiquattro giorni dopo il rapporto.

I due difetti di codice erano stati corretti molto prima del rapporto. La cronologia della divulgazione di Wiz registra l'esecuzione del codice della barriera di protezione segnalata il 18 febbraio 2026 e corretta il 25 febbraio nella v1.82.0, il bypass MCP corretto il 25 aprile nella v1.84.0, lo sfruttamento osservato il 7 luglio, gli identificatori CVE pubblicati l'8 luglio e l'inserimento nel catalogo il 2 settembre. Gli artefatti di rilascio riportano date successive rispetto a quelle delle correzioni: l'indice dei pacchetti mostra la v1.82.0 al 1° marzo 2026 e la v1.84.0 al 14 maggio, che indicano quando ciascuna correzione è diventata installabile anziché quando è stata introdotta. Due record di rilascio ufficiali datano le stesse correzioni più tardi rispetto a tale cronologia. La release v1.82.0-stable su GitHub riporta l'11 marzo 2026 e il pacchetto 1.82.0 su PyPI il 1° marzo; la v1.84.0 è datata 14 maggio 2026 su entrambi. Nulla di quanto pubblicato spiega la discrepanza, e ciò non ha importanza ai fini dell'argomentazione, poiché ognuna di quelle date cade mesi prima del rapporto di settembre. I due avvisi di GitHub aggiungono poi una terza data: sono stati pubblicati il 30 giugno 2026, tre settimane prima degli identificatori CVE che, secondo Wiz, sono stati diffusi l'8 luglio.

Ciò che nessuna di quelle release aveva corretto era il valore predefinito. Wiz ha segnalato che al 9 settembre la chiave master era ancora impostata su sk-1234 durante l'installazione di LiteLLM tramite Docker Compose o pip install, e The Hacker News ha confermato che quel giorno la guida di configurazione utilizzava ancora quel valore. La modifica è arrivata con la v1.104.0, caricata sul Python Package Index il 3 ottobre 2026, le cui note di rilascio la elencano come breaking change: ora il proxy rifiuta di avviarsi con una chiave master non impostata, vuota o pubblicamente nota, indicando nell'errore di avvio l'origine del valore non valido e stampando un comando che ne genera una sicura. Una voce correlata registra una modifica volta a smettere di pubblicizzare un valore debole e pubblicamente noto di chiave master nelle configurazioni e negli esempi distribuiti, e il file docker-compose sul ramo principale del progetto non imposta più alcuna chiave.

Questa è la sequenza da conservare. Il codice è stato corretto in primavera. Il valore che rendeva insufficienti quelle correzioni è rimasto nelle istruzioni di installazione fino a ottobre, e solo allora il software ha iniziato a rifiutarlo. Nessuna delle due correzioni richiedeva che l'altra attendesse.

Ciò che non è cambiato è il percorso pass-through verso il servizio di metadati dell'istanza. Continua a non avere né una CVE né una correzione, perché il progetto considera gli amministratori affidabili. L'elenco di remediazioni di Wiz è quindi per lo più lavoro per gli operatori: una chiave master forte e univoca, una revisione dei guardrail registrati seguita da un riavvio del processo per cancellare il codice mantenuto in memoria, un audit degli endpoint pass-through con egress dei container limitato e ruoli IAM con privilegi minimi. Nessuno di questi quattro si ottiene solo con l'aggiornamento.

Ciò che il fascicolo non stabilisce

• Non è stata individuata alcuna replica indipendente della scansione dei 3.074 host. Il 9,6% è una misurazione di Wiz, e ogni altra trattazione del dato ripete la cifra in forma attributiva.

• Non esiste una cifra attuale dell’esposizione. Il follow-up di agosto ha rilevato più di 85.000 istanze, che secondo Wiz sono per lo più honeypot o distribuzioni di test e non possono essere confrontate con il conteggio di febbraio.

• Nessuna vittima. Nulla nel rapporto nomina un gateway, un operatore o un account cloud compromessi tramite la chiave predefinita, e lo sfruttamento documentato da Wiz è quello del bypass MCP anziché di sk-1234.

• Nessuna prova che i 294 host siano stati utilizzati. La scansione ha verificato se si sarebbero autenticati, un'asserzione più debole rispetto al dimostrare che qualcuno lo abbia effettivamente fatto.

• Nessuna severità definita per il difetto del guardrail. Wiz e i manutentori descrivono lo stesso comportamento e lo valutano in modi molto diversi, e la differenza riguarda i privilegi che ciascuno presume l'attaccante già possieda.

Wiz è anche un fornitore di sicurezza cloud che vende servizi di rilevamento per questa classe di esposizione, e il rapporto si chiude con una sezione su come i suoi prodotti identificano i deployment LiteLLM, le versioni vulnerabili e le istanze shadow. Si tratta di un contesto per leggere la sezione sulla remediation, non di un motivo per sottovalutare una misurazione i cui dettagli tecnici sono corroborati dagli avvisi degli stessi manutentori.

La parte del record che viaggia oltre LiteLLM è lo spazio tra due date. La vulnerabilità è stata chiusa in primavera. Il valore predefinito che rendeva la vulnerabilità problematica per un estraneo veniva ancora stampato nelle istruzioni di installazione a settembre, e il software ha iniziato a rifiutarlo solo a ottobre. Gli operatori che hanno modificato la stringa non hanno mai dovuto aspettare nulla di tutto ciò.