I gateway IA LiteLLM esposti accettano ancora la chiave predefinita sk-1234

Redazione YuSMP Group Team editoriale, YuSMP Group

In breve

Cosa ha scoperto Wiz

LiteLLM è un diffuso gateway IA open source – il software che un’azienda colloca tra le proprie applicazioni e i provider di modelli che paga, così che ogni chiamata LLM passi da un unico punto per instradamento, budget, logging e gestione delle chiavi. Questa architettura rende il gateway comodo, ma anche un punto di concentrazione dei segreti: custodisce le chiavi API di OpenAI, Anthropic, AWS Bedrock, Google e di qualunque altro servizio l’organizzazione utilizzi. Chi controlla il gateway le controlla tutte. Poiché i team li installano sempre più spesso mentre sviluppano agenti IA e copilot interni, il gateway è diventato silenziosamente infrastruttura di produzione – proprio il tipo di componente che i nostri ingegneri classificano come critico per la sicurezza in ogni progetto di agenti IA.

In un rapporto pubblicato il 10 settembre 2026, Wiz Research descrive la scansione delle installazioni LiteLLM esposte su Internet che è riuscita a individuare. Su circa 3.074 istanze trovate su Shodan a febbraio 2026, 294 – quasi una su dieci – accettavano sk-1234, la master key segnaposto presente nella documentazione di LiteLLM. In 191 di questi 294 casi i gestori non avevano impostato alcuna master key, quindi il gateway avrebbe accettato qualsiasi valore. Una successiva scansione ad agosto 2026 ha contato decine di migliaia di istanze in più, molte delle quali sembravano ambienti di test usa e getta; i dati di febbraio rappresentano la base prudente e chiaramente esposta.

Il dettaglio scomodo è che non si tratta di uno zero-day esotico. È una credenziale di esempio documentata, copiata da una guida di installazione e mai cambiata, su un servizio raggiungibile dall’Internet aperto. Al 9 settembre 2026 la guida di LiteLLM mostrava ancora sk-1234 sopra un commento che invita i gestori a sostituirla con un lungo valore casuale prima dell’uso reale – un’indicazione che, a giudicare da questi numeri, una quota significativa delle installazioni ignora.

Come una chiave predefinita diventa una compromissione del cloud

Ciò che trasforma un valore predefinito dimenticato in una violazione completa è che la master key di LiteLLM svolge due funzioni contemporaneamente. È la credenziale di amministratore del proxy ed è anche il segreto HS256 con cui vengono firmati i token di sessione. Un attaccante che conosce la chiave quindi non si limita ad accedere: può emettere token validi per qualsiasi utente e falsificare sessioni arbitrarie su tutto il gateway, senza alcuna modifica alla configurazione. Quando la chiave è un valore stampato in una documentazione pubblica, «conoscerla» è banale.

Da quell’accesso di amministratore, Wiz ha percorso la catena come farebbe un attaccante. Per prima cosa il gateway consegna tutte le chiavi API dei provider di modelli che custodisce – le credenziali a pagamento di ogni fornitore di LLM, pronte per essere abusate o rivendute. In secondo luogo, ed è peggio, i ricercatori hanno raggiunto le credenziali IAM cloud della macchina su cui gira il gateway: endpoint pass-through senza validazione dell’URL permettono di indirizzare una richiesta al servizio di metadati cloud su 169.254.169.254 ed esfiltrare credenziali IAM temporanee – anche su istanze protette da IMDSv2, tramite manipolazione degli header. A quel punto l’incidente non riguarda più un gateway, ma l’account cloud che c’è dietro.

Due vulnerabilità specifiche completano il quadro. CVE-2026-59822 (CVSS 8.8) è un bypass dell’autenticazione nella gestione del Model Context Protocol di LiteLLM: un fallback difettoso considera autenticata una richiesta con qualsiasi bearer token – persino Authorization: Bearer a –, concedendo accesso MCP senza autenticazione. È stata corretta nella v1.84.0 il 25 aprile 2026 ed è stata poi inserita nel catalogo Known Exploited Vulnerabilities della CISA dopo lo sfruttamento reale. CVE-2026-59821 è un’esecuzione di codice post-autenticazione: il codice dei guardrail personalizzati viene eseguito tramite exec/compile senza sandbox, cosa che Wiz ha sfruttato per eseguire comandi come root; è stata corretta nella v1.82.0 il 25 febbraio 2026. Il produttore classifica questo problema dei guardrail come di bassa gravità, una valutazione da confrontare con una shell root dimostrata.

Cosa significa per le aziende italiane

Al di là del nome del prodotto restano tre lezioni durature. Primo, il vostro gateway IA è una cassaforte di credenziali: trattatelo come tale. Nella corsa del 2026 a rilasciare agenti e copilot, molti team hanno installato un proxy LLM come semplice «tubatura» senza mai dargli il modello delle minacce riservato a un database. Eppure custodisce ogni chiave dei provider e, come mostra questa ricerca, offre una strada verso il vostro cloud. La stessa impostazione secure-by-default che applicate agli archivi di produzione – segreti univoci, nessuna esposizione a Internet per impostazione predefinita, ruoli a privilegio minimo – va estesa al livello IA e alla più ampia piattaforma cloud e DevOps su cui gira.

Secondo, i valori predefiniti sono la violazione più antica che esista, e l’infrastruttura IA l’ha appena reimparato. Password predefinite e chiavi di esempio svuotano server da decenni; l’unica novità è che la macchina vulnerabile è un gateway IA. Ogni componente la cui guida introduttiva contiene una credenziale letterale richiede un controllo automatico rigoroso che impedisca al valore di esempio di arrivare in produzione – nella CI, nei template di deployment e in scansioni esterne periodiche di ciò che esponete davvero.

Terzo, chiavi dei provider trapelate e accessi al cloud sono un evento di compliance, non solo un problema operativo. Per i team europei, l’esfiltrazione non autorizzata di credenziali e qualsiasi dato personale o regolamentato che transiti dal gateway rientrano pienamente nelle aspettative di GDPR, NIS2 e DORA in materia di controllo degli accessi e di rimedio rapido e documentato. Per i team che lavorano con clienti statunitensi della sanità o della finanza, la stessa esposizione si traduce in obblighi HIPAA e SOC 2. Sapere quali servizi IA interni sono raggiungibili da Internet – e poter dimostrare che usano credenziali univoche e ruoli a privilegio minimo – è il controllo su cui auditor e autorità vi interrogheranno per primo.

Cosa fare adesso

1. Impostare una master key forte e univoca – e ruotare le chiavi dei provider. Sostituite sk-1234 o qualsiasi valore di esempio documentato con un lungo valore casuale e ruotate ogni chiave API dei provider di modelli memorizzata dal gateway, partendo dal presupposto che possa essere già trapelata.
2. Aggiornare LiteLLM all’ultima release. Andate oltre le correzioni per CVE-2026-59822 (v1.84.0) e CVE-2026-59821 (v1.82.0) e seguite gli advisory del progetto sui problemi MCP e guardrail correlati.
3. Togliere il gateway dall’Internet pubblico. Un proxy LLM dovrebbe essere raggiungibile solo da subnet fidate o dietro una VPN o un proxy zero trust. Se l’accesso pubblico non è un requisito imprescindibile, eliminatelo: basta questo a neutralizzare il rischio delle scansioni di massa.
4. Limitare il raggio d’impatto nel cloud. Limitate il traffico in uscita dei container in modo che il gateway non possa raggiungere l’endpoint dei metadati 169.254.169.254, applicate all’host ruoli IAM a privilegio minimo e preferite meccanismi circoscritti come IRSA a ruoli di istanza troppo ampi.
5. Includere l’infrastruttura IA nei test di sicurezza. Gateway, database vettoriali e runtime degli agenti vengono abitualmente esclusi dalle verifiche, pur custodendo le chiavi più sensibili. Inseriteli nel vostro prossimo penetration test, rivedete le configurazioni dei guardrail e riavviate i processi per eliminare dalla memoria eventuale codice iniettato.

Domande frequenti

Fonti

Wiz Research — Off Guard: Breaking LiteLLM from Authentication Bypass to Cloud Compromise
The Hacker News — Nearly 1 in 10 Exposed LiteLLM Gateways Accepted the Example “sk-1234” Admin Key
CISA — Known Exploited Vulnerabilities Catalog