Infrastrutture AI esposte: come gli attaccanti dirottano gateway come LiteLLM per alimentare agenti autonomi

Il problema: gateway AI esposti diventano armi in mano agli attaccanti

Un report dei ricercatori di Zenity, ripreso da Petri IT Knowledgebase, descrive uno scenario che molti reparti IT non hanno ancora messo in conto: non serve violare la rete aziendale se l’infrastruttura AI è già esposta pubblicamente e priva di protezioni adeguate. Gli attaccanti puntano direttamente gateway di inferenza, endpoint AI e piattaforme di agenti raggiungibili da Internet, configurando i propri agenti per usarli come “model provider” — sfruttando cioè la capacità di calcolo e le credenziali dell’azienda vittima per condurre operazioni offensive, ricognizione e furto di risorse, senza aver mai compromesso un singolo endpoint interno.

Come funziona l’attacco

Secondo Zenity, gli attaccanti indirizzano tool di penetration testing autonomi come Strix e HexStrike AI, oltre a workflow basati su OpenAI Codex, verso infrastrutture esposte pubblicamente. In diversi casi osservati, gli agenti venivano istruiti per operare in modo aggressivo e occultare la propria identità durante la ricognizione e i test contro bersagli esterni. I ricercatori hanno inoltre trovato ambienti di sviluppo, cronologie Git, script di ricognizione e altri dettagli operativi esposti involontariamente proprio attraverso questi stessi workflow AI mal configurati.

Un bersaglio ricorrente in questi attacchi è LiteLLM, il gateway open source usato per unificare l’accesso a decine di provider LLM (OpenAI, Anthropic, Azure OpenAI e altri) e adottato da framework molto diffusi come CrewAI, DSPy e Microsoft GraphRAG, con circa 97 milioni di installazioni mensili da PyPI. Proprio questa diffusione lo rende un bersaglio ad alto ritorno per chi cerca infrastrutture da dirottare.

Le vulnerabilità sfruttate

Da marzo 2026 LiteLLM ha accumulato sei CVE distinte e un incidente di supply chain, con la catena più grave che raggiunge un CVSS di 10.0 e consente RCE non autenticata su qualunque proxy esposto. Le più rilevanti:

• CVE-2026-42271 — command injection (CVSS 8.7): gli endpoint POST /mcp-rest/test/connection e POST /mcp-rest/test/tools/list, pensati per testare un server MCP prima di salvarlo, accettano una configurazione completa nel body della richiesta. Con una configurazione di tipo stdio, il proxy tenta la connessione eseguendo il comando fornito come sottoprocesso direttamente sull’host.
• CVE-2026-47101 / CVE-2026-47102 — escalation di privilegi (CVSS 9.9): un utente a basso privilegio può ottenere diritti di amministratore ed eseguire codice arbitrario sul server LiteLLM.
• CVE-2026-40217 — sandbox escape: gli endpoint di guardrail riservati agli admin accettano codice Python fornito dall’utente e lo compilano con exec(); omettendo la chiave __builtins__ dal dizionario globals ci si aspetterebbe un ambiente ristretto, ma Python inietta automaticamente l’intero modulo builtins quando quella chiave manca, aprendo di fatto l’accesso alla shell.
• SSRF su /chat/completions — un api_base controllato dall’attaccante permette di dirottare le richieste verso un dominio arbitrario, esponendo potenzialmente la chiave API nell’header Authorization.
• Supply chain attack — nel marzo 2026 le versioni compromesse litellm==1.82.7 e litellm==1.82.8 sono rimaste pubblicate su PyPI per circa 40 minuti prima di essere messe in quarantena.

Il fattore comune che rende possibile lo sfruttamento su larga scala è banale: LITELLM_MASTER_KEY non ha un valore di default e, seguendo la guida rapida ufficiale, è facile finire in produzione con un gateway completamente privo di autenticazione posizionato davanti alle chiavi API più costose dell’organizzazione.

Come mettere in sicurezza la propria infrastruttura AI

Le raccomandazioni di Zenity e della documentazione ufficiale di LiteLLM si possono tradurre in una checklist operativa per chi gestisce questo tipo di infrastruttura:

• Non esporre mai il gateway direttamente su Internet. Endpoint di inferenza e piattaforme agent vanno trattati come qualunque altro sistema internet-facing: dietro reverse proxy con autenticazione forte, VPN o segmentazione di rete dedicata.
• Impostare sempre LITELLM_MASTER_KEY prima di qualunque deployment, anche di test, e non affidarsi mai alla configurazione di default della quickstart in ambienti raggiungibili dall’esterno.
• Aggiornare tempestivamente. Gli attaccanti hanno iniziato a sfruttare le vulnerabilità di LiteLLM a ridosso della pubblicazione delle patch: la versione consigliata è la 1.83.14 o successiva, insieme all’aggiornamento di Starlette alla 1.0.1+.
• Gestire i segreti fuori dall’ambiente locale. Le variabili d’ambiente sono comode in sviluppo ma restano un anti-pattern in produzione perché facilmente leggibili e spesso finiscono nei log delle pipeline CI/CD: meglio un vault dedicato (HashiCorp Vault, Azure Key Vault, AWS Secrets Manager).
• Isolare il filesystem dei container. In Kubernetes, readOnlyRootFilesystem: true è pienamente supportato da LiteLLM e riduce la superficie di attacco in caso di RCE.
• Applicare policy granulari con OPA (Open Policy Agent) per definire in modo esterno e verificabile chi può accedere a quali risorse del gateway.
• Monitorare l’utilizzo. Picchi anomali nel consumo dei modelli, pattern di richieste insoliti o attività fuori orario sono spesso il primo segnale di un uso non autorizzato delle risorse AI aziendali.
• Ruotare tutte le credenziali — chiavi dei provider LLM, password del database, master key, chiavi SSH e credenziali cloud — non appena si sospetta una compromissione, dato che un proxy AI compromesso ha tipicamente accesso a tutto questo.

Conclusione

Il messaggio di fondo del report è semplice: l’infrastruttura AI aziendale merita la stessa attenzione di sicurezza riservata a qualunque altro sistema esposto su Internet, né più né meno. I gateway come LiteLLM stanno diventando componenti critici tanto quanto un database o un server web, ma la velocità con cui sono stati adottati ha spesso lasciato indietro le pratiche di hardening di base — a partire da una master key non configurata. Per chi gestisce questi sistemi, la checklist sopra rappresenta il minimo indispensabile prima di collegare un gateway AI a Internet.

Fonti: Petri IT Knowledgebase – Attackers Exploit Exposed Enterprise AI Infrastructure to Power Autonomous Agents; Obsidian Security – Breaking LiteLLM; The Hacker News – LiteLLM Flaw CVE-2026-42271 Exploited in the Wild.