I gateway AI diventano la superficie di attacco — l'inserimento in KEV di LiteLLM e il percorso attraverso le chiavi, MCP e il cloud
Il bypass di autenticazione MCP di BerriAI LiteLLM (CVE-2026-59822) è entrato nel catalogo KEV di CISA, e Microsoft segnala attaccanti che usano gateway LiteLLM per consegnare XMRig. La ricerca di Wiz ha trovato che circa 1 su 10 di ~3,000 istanze pubbliche accettava la chiave predefinita sk-1234 oppure girava senza autenticazione. Esaminiamo che cosa significa che l'infrastruttura AI sia una cassaforte di credenziali.
Questo articolo è stato tradotto automaticamente.
Nel settembre 2026, CISA ha aggiunto il bypass di autenticazione MCP di BerriAI LiteLLM, CVE-2026-59822, al proprio catalogo Known Exploited Vulnerabilities (KEV) (2 settembre, secondo la cronologia di Wiz). Il difetto consente a un token Bearer arbitrario di stabilire una sessione autenticata valida sull'endpoint MCP Streamable HTTP di LiteLLM, ed è comparso accanto ad altri sei difetti sfruttati — inclusi SonicWall SMA 1000 e Sangoma Switchvox — nell'aggiornamento KEV di inizio settembre (secondo The Hacker News). LiteLLM è un gateway AI open source che detiene le chiavi API di ogni provider LLM configurato; secondo la stima di Wiz è presente in circa un terzo degli ambienti cloud.
I fatti: (1) La ricerca di Wiz (pubblicata il 9 settembre) ha trovato che, di circa 3,000 istanze LiteLLM esposte a Internet, circa il 9.6% accettava la chiave master predefinita sk-1234 oppure non richiedeva alcuna autenticazione. Nelle istanze senza autenticazione configurata, a ogni utente veniva concesso PROXY_ADMIN per impostazione predefinita, raggiungendo funzionalità di admin senza credenziali (da allora corretto). (2) Con diritti di admin, un attaccante può usare la funzione di endpoint pass-through per fare da proxy delle richieste verso URL interni arbitrari — incluso il servizio di metadati AWS — e il meccanismo di inoltro degli header x-pass- vanifica il requisito di session token di IMDSv2, consentendo il furto di credenziali IAM cloud. (3) A settembre, Microsoft ha segnalato attaccanti che concatenano CVE-2026-42271 e CVE-2026-48710 (il bypass di autenticazione Starlette «BadHost») per entrare nei gateway LiteLLM e consegnare un miner XMRig tramite un binario ELF (secondo The Hacker News). Gli attacchi alle istanze RAGFlow esposte, nel frattempo, hanno prodotto chiavi di provider LLM e metadati rubati, piuttosto che ransomware.
Analisi (separata dai fatti): ciò che queste storie mostrano è che i gateway AI sono andati oltre lo stadio del «LLMjacking» — spendere il budget API di qualcun altro — per diventare un percorso di intrusione cloud a pieno titolo. LiteLLM esegue Python lato server a ogni richiesta di inferenza, può fare da proxy delle richieste verso URL interni arbitrari e si connette a strumenti esterni via MCP. Non è soltanto una cassaforte di chiavi; è un ponte verso la rete interna con capacità di esecuzione. Asset che i difensori preferiscono mettere da parte sotto un principio di progetto «è AI, tienilo interno» diventano, per gli attaccanti, un percorso a più stadi verso chiavi, IAM e API interne dietro un singolo bypass di autenticazione. Il divario strutturale tra i default progettati per l'esperienza dello sviluppatore (sk-1234, PROXY_ADMIN quando non configurato) e il deployment in produzione merita di essere nominato come tale.
Implicazioni difensive: (1) Se si esegue LiteLLM, aggiornare prima a v1.84.0 o successivo (correzione di CVE-2026-59822) e a v1.83.7 o successivo (correzione di CVE-2026-42271), più Starlette 1.0.1 o successivo; confermare che la chiave master predefinita sia stata cambiata e che l'istanza non sia esposta a Internet. (2) Ruotare tutte le chiavi API dei provider memorizzate come se fossero compromesse nel momento in cui l'esposizione è confermata, e impostare limiti di spesa per contenere il danno quando una chiave esce. (3) Trattare le funzioni che portano esecuzione di codice arbitrario o proxy di URL arbitrari — MCP, endpoint pass-through — come permessi a livello di agent da inventariare separatamente e disabilitare per impostazione predefinita. (4) Controllare altri gateway AI e orchestratori LLM con la stessa lente: credenziali predefinite, funzionalità di admin esposta, proxy di URL interni. Queste sono la nostra analisi, non una guida del vendor.
I fatti di questo articolo sono tratti principalmente dalla ricerca di Wiz (https://www.wiz.io/blog/off-guard-breaking-litellm-from-authentication-bypass-to-cloud-compromise), dalla release di correzione di BerriAI LiteLLM (https://github.com/BerriAI/litellm/releases/tag/v1.83.7-stable) e dal catalogo KEV di CISA (https://www.cisa.gov/known-exploited-vulnerabilities-catalog), con la cronaca di The Hacker News come fonte secondaria (https://thehackernews.com/2026/09/cisa-adds-5-actively-exploited.html e https://thehackernews.com/2026/09/cisa-adds-seven-exploited-flaws-as.html); la data KEV del 2 settembre segue la cronologia di Wiz. Le sezioni di analisi sono tenute separate dal resoconto fattuale. Si noti che i conteggi delle istanze e la quota degli ambienti cloud sono stime che dipendono dal momento e dal metodo di misurazione.