LiteLLM sotto accusa: una chiave di esempio “sk‑1234” espone quasi il 10 % dei gateway AI

Negli ultimi mesi la sicurezza dei gateway AI open‑source è tornata al centro del dibattito, dopo che Wiz Research ha scoperto che quasi uno su dieci dei server LiteLLM esposti su Internet accetta la chiave di amministratore di esempio “sk‑1234”. La scoperta, pubblicata il 9 settembre, mette in luce una vulnerabilità di fondo: la stessa chiave è sia la credenziale di amministrazione sia l’interruttore che abilita l’autenticazione. In un contesto in cui le imprese stanno integrando modelli di linguaggio di grandi dimensioni (LLM) in processi critici, la possibilità che un attaccante ottenga il controllo di un gateway equivale a possedere una chiave di livello Tier‑0 per l’intera infrastruttura AI.

Il contesto: diffusione di LiteLLM e la superficie di attacco

LiteLLM è un gateway AI open‑source nato per semplificare il collegamento tra le applicazioni aziendali e i provider di modelli (OpenAI, Anthropic, Azure, ecc.). La sua adozione è cresciuta rapidamente perché consente di centralizzare le chiavi API, gestire policy di routing e monitorare i prompt. Tuttavia, la natura “internet‑facing” di molte implementazioni – spesso esposte per test o demo – ha creato una superficie di attacco ampia. Wiz ha identificato 3 074 istanze su Shodan a febbraio; di queste, 294 hanno accettato la chiave di esempio, e in 191 casi la chiave non era stata impostata affatto. Un secondo scan ad agosto ha rilevato oltre 85 000 istanze, sebbene la maggior parte sembrasse appartenere a honeypot o ambienti di test. La persistenza della chiave “sk‑1234” nella documentazione di LiteLLM, accompagnata solo da un commento che invita a sostituirla, è il fattore scatenante di questa esposizione.

Le vulnerabilità emerse: dalla chiave di default al codice eseguibile

La chiave di esempio svolge due ruoli critici. Prima, è la credenziale di amministratore: chi la possiede può leggere tutte le chiavi API dei provider archiviate sul server. Seconda, abilita il “pass‑through” routing, una funzionalità che permette di inoltrare richieste a URL arbitrari senza filtri su indirizzi privati o metadata service. Un attaccante con la chiave può quindi puntare il routing verso l’endpoint di metadata dell’istanza cloud (ad esempio 169.254.169.254) e rubare le credenziali IAM del nodo. Anche la recente vulnerabilità CVE‑2026‑59822, che consente a un attaccante non autenticato di aprire una sessione MCP con un token di un solo carattere, dimostra quanto sia facile scalare da un semplice “ping” a un furto di credenziali di livello cloud.

Un’altra falla, CVE‑2026‑42271, permette a un utente autenticato di eseguire comandi sul host tramite endpoint MCP. Quando combinata con la vulnerabilità Starlette (CVE‑2026‑48710), l’attacco può essere effettuato senza credenziali, come dimostrato da Horizon3.ai, che ha osservato l’installazione di miner di criptovalute su gateway compromessi. Microsoft, in un caso di agosto, ha confermato che gli aggressori hanno sfruttato queste catene per leggere la chiave master, le chiavi dei provider e la stringa di connessione al database PostgreSQL interno, esfiltrando dati sensibili sui modelli e le chiavi virtuali.

Le correzioni rilasciate (versione 1.84.0 e successive) coprono le CVE note, ma non affrontano il problema di design del pass‑through verso i metadata service, che LiteLLM non considera una vulnerabilità. Di conseguenza, le organizzazioni devono affidarsi a controlli di rete (es. blocco di egress verso 169.254.0.0/16) e a ruoli IAM strettamente limitati per mitigare il rischio.

Implicazioni per le imprese e le risposte del mercato

Per le aziende che hanno già adottato LiteLLM come “secret store” di livello Tier‑0, la scoperta di Wiz rappresenta un campanello d’allarme. La perdita di una chiave master equivale a una compromissione dell’intera catena di fornitura AI: gli aggressori possono consumare i crediti dei provider, generare contenuti dannosi o, peggio, accedere a sistemi interni tramite il Model Context Protocol (MCP). La risposta del mercato è stata rapida: i principali vendor di sicurezza cloud hanno aggiornato i loro playbook di hunting includendo query specifiche per rilevare traffico MCP anomalo e per identificare gateway LiteLLM con la chiave di default. Inoltre, CISA ha inserito la vulnerabilità CVE‑2026‑59822 nel suo catalogo di vulnerabilità sfruttate, imponendo alle agenzie federali di mitigare entro il 16 settembre.

Le best practice emergenti includono:
* **Rotazione obbligatoria della chiave master** durante il deployment, con generazione di valori casuali lunghi.
* **Disabilitazione del pass‑through routing** o, in alternativa, whitelist rigorosa degli URL consentiti.
* **Implementazione di network egress filtering** per bloccare l’accesso ai metadata service da container non privilegiati.
* **Separazione dei ruoli IAM**: il servizio LiteLLM dovrebbe operare con privilegi minimi, evitando l’uso di credenziali di amministratore cloud.

Il caso evidenzia anche la necessità di una governance più forte per i progetti open‑source critici: la policy di sicurezza di LiteLLM dichiara esplicitamente che errori di configurazione (come la mancata impostazione della chiave master) non sono “in scope”. Tale approccio è ora sotto scrutinio, poiché le aziende non possono più considerare la configurazione di base come “non vulnerabile”.

Prospettive e Scenari

Guardando al futuro, la sicurezza dei gateway AI diventerà un elemento centrale della strategia di difesa per le imprese. Con l’aumento dell’adozione di LLM in ambiti sensibili (finanza, sanità, difesa), i regulator probabilmente introdurranno requisiti di certificazione per i componenti di integrazione, includendo controlli su chiavi di amministrazione e routing di rete. Nel frattempo, gli attaccanti continueranno a sfruttare configurazioni di default e catene di vulnerabilità non ancora coperte da patch. Le organizzazioni dovranno quindi investire in monitoraggio continuo, automazione della rotazione delle credenziali e audit di configurazione per mantenere il controllo su questi “Tier‑0” segreti. Solo così sarà possibile limitare l’esposizione a scenari di “LLMjacking” e garantire che l’AI rimanga un vantaggio competitivo, non una porta d’ingresso per minacce avanzate.