Il gateway dell’AI custodisce tutte le chiavi, e lo stanno già attaccando: l’infrastruttura AI va gestita come produzione

Per far dialogare le applicazioni aziendali con i modelli linguistici, molte organizzazioni hanno inserito nel mezzo un componente che raramente compare negli schemi dell’infrastruttura: un gateway AI. Smista le richieste verso il fornitore giusto, conta i consumi e, sempre più spesso, collega i modelli agli strumenti aziendali attraverso il Model Context Protocol (MCP). Uno dei più diffusi è LiteLLM, progetto open source che si avvia con un container.

Il 17 settembre il CSIRT Italia ha segnalato nel suo bollettino settimanale lo sfruttamento in rete di una vulnerabilità di LiteLLM (CVE-2026-59822): un attaccante remoto, senza credenziali, può aggirare l’autenticazione e accedere agli strumenti MCP configurati. Due settimane prima l’agenzia americana CISA l’aveva inserita nel catalogo delle vulnerabilità sfruttate; a giugno vi era già finita un’altra falla dello stesso prodotto (CVE-2026-42271), anch’essa legata alla gestione dei server MCP. Due porte d’ingresso nello stesso componente in tre mesi.

Cosa è successo, in ordine

La falla di settembre è quasi banale. Quando la verifica della chiave di accesso falliva, un meccanismo di ripiego pensato per l’autenticazione OAuth2 sostituiva l’identità mancante con un oggetto vuoto, invece di rifiutare la richiesta. Un token inventato apriva così una sessione valida, con cui invocare gli strumenti collegati e raggiungere i servizi retrostanti: nelle trappole dei ricercatori di Wiz bastavano token di un solo carattere. Sono vulnerabili le versioni precedenti alla 1.84.0.

La cronologia è la parte che conta. La versione corretta era disponibile dalla primavera; l’avviso pubblico del progetto è del 30 giugno; il primo sfruttamento osservato dalle trappole di Wiz è del 7 luglio; l’inserimento nel catalogo CISA del 2 settembre; la segnalazione del CSIRT Italia del 17. Chi è stato colpito non è stato sorpreso da uno zero-day: usava un software rimasto indietro di mesi.

Perché proprio il gateway

Un gateway AI concentra, per costruzione, ciò che un attaccante cerca. Secondo la ricerca pubblicata da Wiz il 9 settembre, chi possiede la chiave principale di LiteLLM legge le chiavi API di tutti i fornitori configurati e, nei test dei ricercatori, è arrivato fino alle credenziali cloud della macchina che ospita il gateway, tramite una funzione di inoltro che il progetto considera legittima per gli amministratori. Poi ci sono gli strumenti MCP: se un modello è collegato al repository del codice o a un database, lo è anche chi ne dirotta la sessione.

E spesso quella chiave non serve nemmeno rubarla. Nella scansione condotta a febbraio su 3.074 istanze LiteLLM esposte su internet, 294 — quasi una su dieci — accettavano la chiave predefinita sk-1234; 191 di queste perché non chiedevano alcuna autenticazione.

Cosa fanno gli attaccanti, una volta dentro

Il rapporto di Wiz su novanta giorni di attacchi contro trappole che imitavano servizi AI — LiteLLM, Langflow, Flowise, Ollama e altri — descrive tre schemi ricorrenti.

• Sfruttamento dei server MCP. Con la falla di giugno, gli attaccanti facevano «testare» al gateway una finta configurazione che installava un miner di criptovaluta, restituendo una risposta regolare perché la prova sembrasse riuscita.
• Prompt injection alla cieca contro agenti con accesso alla shell, con il successo confermato da richieste DNS verso domini dell’attaccante.
• Post-exploitation già specializzata: chiave principale estratta dalla memoria del processo, ricerca dei file di configurazione, identificazione del fornitore di modelli per decidere se rubarne la chiave, consumarne il credito a spese della vittima o passare oltre.

Mining e furto di credito sono il danno visibile. Quello meno visibile è che dal gateway passano prompt e risposte: documenti, codice e dati che i dipendenti affidano ai modelli.

Il vero problema: nessuno l’ha messo in inventario

Le falle sono state corrette; la lezione resta. Il gateway AI tipico nasce dove nascono le sperimentazioni: un team di sviluppo, un container avviato «per provare», una chiave d’esempio mai cambiata, una porta aperta per i colleghi. Non passa dalla gestione delle patch, non manda log al monitoraggio, non ha un responsabile che legga i bollettini. Diventa produzione senza che nessuno l’abbia deciso.

L’infrastruttura AI non è un esperimento degli sviluppatori: è un pannello di controllo che conosce le chiavi di tutti i modelli e degli strumenti che i modelli possono usare.

Dalle indicazioni di ricercatori e manutentori si ricava una lista di verifiche concreta:

• Censire ogni componente AI — gateway, server MCP, motori di inferenza — con versione, esposizione e proprietario, compresi quelli nati come prova.
• Togliere l’esposizione diretta a internet e verificare che un token inventato venga rifiutato: se il gateway apre comunque una sessione, è vulnerabile, qualunque versione dichiari.
• Sostituire chiavi predefinite o condivise e, se l’istanza è rimasta esposta nei mesi a rischio, ruotare tutte le credenziali che custodiva.
• Ridurre il raggio d’azione: privilegi minimi per l’identità cloud del gateway, traffico in uscita limitato, strumenti MCP in sola lettura dove la scrittura non serve.
• Sorvegliare il comportamento: un server AI che avvia una shell o contatta indirizzi sconosciuti è un segnale da raccogliere, comunque l’attaccante sia entrato.

Per chi ha ricevuto nella primavera del 2025 la comunicazione di inserimento nell’elenco NIS, inventario degli asset e gestione delle vulnerabilità sono tra le misure di base da rendere operative proprio in queste settimane. Un gateway AI assente dall’inventario non regge una verifica.

Il nostro punto di vista

Nei nostri assessment la domanda di partenza è sempre la stessa: che cosa esponete davvero? Oggi la risposta deve includere anche i componenti AI che nessuno ha segnalato all’IT — un gateway in un container, un server MCP di prova rimasto acceso. Censirli e verificarli fa parte del nostro lavoro di vulnerability assessment e remediation, con lo stesso metro che applichiamo a un firewall o a un gateway VPN.

Il secondo passo è decidere dove far vivere l’AI di produzione. Un gateway in un’infrastruttura gestita, con aggiornamenti pianificati, segmentazione e log che confluiscono nel SOC · Smart Care, smette di essere un punto cieco. L’AI può restare rapida da adottare; non può restare fuori dal perimetro che si governa.