Sicurezza AI: i router LLM diventano il punto debole della supply chain (caso LiteLLM)

Una ricerca sistematica di UC Santa Barbara, UC San Diego, Fuzzland e World Liberty Financial ha analizzato 428 router commerciali e gratuiti, individuando intermediari che riscrivono attivamente le tool-call degli agenti di coding ed esfiltrano credenziali. L’incidente LiteLLM del marzo 2026 conferma, su scala industriale, che la minaccia non è più teorica.

Sicurezza AI a rischio: perché i router LLM stanno diventando il nuovo punto debole negli attacchi informatici

Ogni volta che un agente LLM, un Claude Code, un Codex o un Cursor, invia una richiesta a un provider di modelli, il traffico attraversa quasi sempre uno o più intermediari applicativi. Si chiamano router, o API gateway, e aggregano decine di provider dietro un’unica interfaccia compatibile con OpenAI. Gestiscono fallback, bilanciamento di carico e ottimizzazione dei costi; un singolo cambio di base URL e una nuova chiave API bastano per instradare un’intera flotta di agenti attraverso un servizio terzo.

La scelta è così banale che, in molte organizzazioni, viene presa al livello di una configurazione di sviluppo. Il fatto che, una volta puntato quel percorso, il client non abbia alcun modo di verificare crittograficamente cosa abbia davvero prodotto il modello a monte è un dettaglio che, fino a poco tempo fa, quasi nessuno ha considerato.

Un gruppo di ricercatori guidato da Hanzhi Liu (UC Santa Barbara), con Chaofan Shou (Fuzzland), Hongbo Wen (UCSB), Yanju Chen (UC San Diego), Ryan Jingyang Fang (World Liberty Financial) e Yu Feng (UCSB), ha deciso di misurarlo. Il paper «Your Agent Is Mine» (arXiv:2604.08407v1, cs.CR, 9 aprile 2026) è il primo studio sistematico sull’ecosistema dei router LLM visti come confine di fiducia della supply chain dell’IA. Il risultato è meno rassicurante del previsto.

Un man-in-the-middle “legittimo” nella sicurezza AI

Il modello di minaccia formalizzato dagli autori parte da un’osservazione architetturale semplice: il router, per sua natura, termina la sessione TLS lato client e ne apre una nuova verso il provider. Occupa quindi una posizione di man-in-the-middle applicativo non accidentale, ma intenzionalmente configurata dall’utente. Nessun TLS downgrade, nessuna forgery di certificati: basta che il client abbia puntato l’endpoint a quel servizio. Da lì il router vede in chiaro tool definition, prompt di sistema, chiavi API, output dei tool e, soprattutto, le tool-call che l’agente sta per eseguire. Può leggerle, trattenerle, riscriverle o fabbricarle ex novo.

La chain-integrity, notano gli autori, è una proprietà del tipo weakest link: in una catena di k hop (utente -> rivenditore -> aggregatore -> OpenRouter -> provider, tanto per restare su uno scenario realistico), un singolo router malevolo in qualunque posizione è sufficiente a compromettere l’intera traiettoria. Gli hop onesti a valle non possono né rilevare né annullare la modifica, perché non hanno alcun riferimento alla risposta originale prodotta dal provider.

Attacchi hacker AI: le 4 tecniche che sfruttano i router LLM

Su questa base, il team costruisce una tassonomia di quattro classi. Le due primitive di base sono AC-1, ovvero response-side payload injection, in cui il router riscrive gli argomenti JSON di una tool-call dopo che il modello ha risposto ma prima che il client la esegua, e AC-2, ovvero passive secret exfiltration, in cui il router si limita a leggere il traffico e a conservare asincronamente chiavi API, PAT GitHub, token AWS, chiavi private Ethereum, chiavi PEM.

A queste si aggiungono due varianti di evasione adattiva. AC-1.a (dependency-targeted injection) sostituisce nel comando di installazione un nome di pacchetto legittimo con un typosquat preregistrato su PyPI o npm, lasciando invariato il resto della riga di comando e ingannando così le approval UI basate sui domini. L’esempio che figura nel paper è istruttivo: pip install requests viene riscritto in pip install reqeusts , una singola lettera invertita, un pacchetto preregistrato dall’attaccante, una dipendenza che viene memorizzata nella cache locale e reimportata in ogni sessione futura.

Un foothold di supply chain durevole ottenuto in uno scambio JSON. AC-1.b (conditional delivery) attiva la riscrittura solo quando un predicato di sessione è verificato: dopo N richieste benigne, per client in modalità autonoma (cosiddetta YOLO, in cui l’agente esegue i tool senza chiedere conferma comando per comando), in determinate finestre orarie o per progetti scritti in linguaggi target. Il predicato vive server-side, è opaco al client, e rende strutturalmente inadeguato qualunque audit black-box di lunghezza finita.

Il punto architetturale, sottolineano gli autori, è che questi attacchi sono ortogonali alla prompt injection: non modificano il ragionamento del modello, agiscono sul layer JSON a valle dell’inferenza. Si compongono con le difese lato modello anziché sostituirle.

Vulnerabilità reali: cosa succede dentro i router LLM

Il dataset combina due popolazioni. La prima è costituita da 28 router a pagamento acquistati da Taobao, Xianyu e vetrine Shopify, mercati dove, come documentato da inchieste precedenti di ChinaTalk, alcuni negozi accumulano oltre 30 000 ordini ripetuti solo per la rivendita di accesso API. La seconda è composta da 400 router gratuiti raccolti da community pubbliche, link in chiaro e dump di configurazione. La maggior parte è costruita sui due template open source più diffusi, sub2api (circa 11 000 stelle su GitHub) e new-api (25 400 stelle, 1,25 milioni di pull da Docker Hub), il cui fork a monte one-api ne conta altre 30 500 con 1,19 milioni di pull.

Testati con una pipeline automatizzata che genera tool-call realistiche a partire da TerminalBench 2.0 e le esegue in sandbox monitorate, i numeri sono i seguenti: 1 router a pagamento e 8 gratuiti iniettano attivamente codice malevolo nelle risposte, riscrivendo comandi o dipendenze prima della consegna al client; 17 router gratuiti generano attività AWS successiva attribuibile a credenziali canary di ricerca osservate in transito; 1 router drena ETH da una chiave privata Ethereum predisposta come esca.

Due router implementano già in produzione logiche di evasione adattiva: uno attiva la riscrittura solo dopo cinquanta chiamate pulite, un altro la riserva a sessioni in modalità YOLO e a progetti scritti in Rust o Go. Logica operativa, non esotica, sufficiente a lasciar passare puliti gli smoke test superficiali e a eseguire il rewrite solo su sessioni di alto valore.

Caso LiteLLM: il primo grande attacco alla supply chain AI

La parte più inquietante è che uno scenario analogo è già avvenuto alla scala di un progetto di riferimento. Tra le 10:39 UTC e le 16:00 UTC del 24 marzo 2026, due versioni compromesse del pacchetto Python litellm, la 1.82.7 e la 1.82.8, sono rimaste pubblicate su PyPI, caricate direttamente dal gruppo noto come TeamPCP dopo aver ottenuto le credenziali PyPI del maintainer attraverso una precedente compromissione di Trivy, lo scanner di vulnerabilità open source usato nella CI/CD di LiteLLM stessa.

La campagna complessiva è tracciata dal CVE-2026-33634 (CVSS v4.0 Base 9,4, CVSS v3.1 Base 8,8, CWE-506 Embedded Malicious Code), formalmente assegnato alla vulnerabilità di Trivy che ha fatto da testa di ponte, e successivamente inserita dalla CISA nel catalogo Known Exploited Vulnerabilities.

I pacchetti LiteLLM contenevano un credential stealer embedded nel file proxy_server.py ed esfiltravano verso un dominio di typosquatting (models.litellm[.]cloud); la versione 1.82.8 aggiungeva inoltre un file litellm_init.pth che veniva eseguito a ogni invocazione dell’interprete Python sull’host, indipendentemente dall’import esplicito di LiteLLM. Endor Labs ha descritto il payload come un credential harvester su chiavi SSH, credenziali cloud, secret Kubernetes, wallet di criptovaluta e file .env, accompagnato da un toolkit di lateral movement Kubernetes e da una backdoor systemd persistente (sysmon.service).

I clienti di LiteLLM Cloud e quelli che usavano l’immagine Docker ufficiale LiteLLM Proxy non sono stati impattati, perché quelle pipeline pinnano le dipendenze in requirements.txt ; a essere colpiti sono stati chi ha eseguito pip install litellm senza pin di versione nella finestra di esposizione e chi aveva LiteLLM come dipendenza transitiva non pinnata, ad esempio tramite framework di agenti, server MCP o orchestrator LLM.

LiteLLM non è un caso limite: secondo i dati riportati da Snyk e Zscaler ThreatLabz, il pacchetto viene scaricato circa 3,4 milioni di volte al giorno ed è integrato nelle pipeline di produzione di migliaia di organizzazioni. Wiz, nella propria analisi dell’incidente, riporta che litellm è presente nel 36 per cento di tutti gli ambienti cloud osservati. L’episodio ha dimostrato, in un contesto produttivo reale, esattamente la primitiva su cui il paper UCSB costruisce il suo threat model: una volta compromesso il pipeline delle richieste di un router ampiamente deployato, ogni tool-call, chiave API e prompt di sistema in transito è esposto alla riscrittura o all’estrazione, senza necessità di rompere il TLS o i pesi del modello.

Perché anche i router “sicuri” possono essere compromessi

Il cuore politico del paper è però la terza sezione empirica: i due studi di poisoning. L’idea è che i router apparentemente benigni possano essere trascinati nello stesso perimetro di attacco non perché cambi il gestore, ma perché la catena a monte viene inquinata.

Nel primo esperimento i ricercatori hanno pubblicato intenzionalmente una chiave OpenAI di ricerca su forum cinesi, gruppi WeChat e Telegram frequentati da operatori di relay. Una sola chiave ha processato cento milioni di token GPT-5.4 e più di sette sessioni Codex distinte. In almeno una di quelle sessioni, precisano gli autori, sono state osservate più credenziali distinte transitare dietro la stessa chiave condivisa; un pattern compatibile sia con il riuso diretto da parte dell’operatore del router sia con il riuso all’interno di una catena di relay più lunga.

Nel secondo esperimento il team ha deployato decoy volutamente deboli: istanze claude-relay-service vulnerabili su venti domini, e istanze Sub2API e CLIProxyAPI con password deboli su venti indirizzi IP. I decoy hanno ricevuto oltre 40 000 tentativi di accesso non autorizzati da 147 IP distinti con sei fingerprint JA3 unici, hanno servito circa due miliardi di token GPT-5.4 e 5.3-codex, hanno esposto all’incirca tredici gigabyte di traffico downstream in chiaro e hanno raccolto 99 credenziali distinte su 440 sessioni Codex e 398 progetti o host.

Qui arriva il dato che dovrebbe interessare chiunque si occupi di governance dell’IA generativa in azienda. Di quelle 440 sessioni, tutte esponevano almeno un percorso di esecuzione shell riscrivibile, e 401 giravano già in modalità YOLO, cioè con l’auto-approvazione dei tool attivata lato client. Per 401 sessioni su 440, l’AC-1.b sofisticato con predicati di sessione non sarebbe nemmeno servito: sarebbe bastata la versione più grezza dell’iniezione di payload. L’autonomia del client, in altre parole, è già da sola la superficie di attacco.

Come difendersi dagli attacchi AI oggi

Gli autori implementano anche Mine, un proxy di ricerca che porta in produzione tutte e quattro le classi di attacco contro quattro framework pubblici (OpenClaw, OpenCode, Codex di OpenAI, Claude Code di Anthropic) e, soprattutto, tre difese immediatamente deployabili senza cooperazione del provider. Mine non viene distribuito pubblicamente: nell’appendice etica gli autori motivano la scelta come una valutazione classica di ricerca dual-use.

La prima difesa è un policy gate fail-closed sui tool ad alto rischio: blocca ogni campione AC-1 e AC-1.a del benchmark sintetico con un tasso di falsi positivi dell’1 per cento e un costo di decisione mediano di 2,3 microsecondi. Difesa robusta sul perimetro comportamentale ingenuo, ma non a prova di avversario consapevole: sullo stesso benchmark, se l’attaccante ospita il payload su un dominio già in allowlist o pre-posiziona uno stager locale da richiamare in seguito, il gate viene bypassato nel cento per cento dei casi. Lo si consideri quindi un filtro grossolano per i workflow più ovvi, non una linea di difesa completa.

La seconda è una anomaly detection sulle risposte, basata su Isolation Forest e cinque feature (punteggio di rischio shell, frequenza del tool nella sessione, entropia degli argomenti, pattern sospetti di secret, deviazione dallo schema). A un budget di falsi positivi del 6,7 per cento intercetta l’89 per cento dei payload AC-1, il 50 per cento degli AC-1.a e circa il 51 per cento degli AC-1.b. Utile come strumento di prioritizzazione della review, non come gate di blocco. L’ablation presentata nell’appendice mostra che il grosso del segnale deriva dal punteggio di rischio shell: rimuoverlo fa precipitare la detection di AC-1 al 17,6 per cento, a conferma che il detector è essenzialmente un filtro sintattico specializzato su una classe di comandi.

La terza è un log di trasparenza append-only che registra body di richiesta e risposta, URL del router, metadati TLS e hash dei byte grezzi della risposta dopo redazione dei secret. Non previene nulla, ma costa circa 12 MB ogni mille sessioni (1,26 KB per entry) e consente, a posteriori, di delimitare l’esposizione quando una chiave o un operatore vengono considerati sospetti. È il tipo di controllo che, nell’ottica di un SOC, chiude il ciclo di incident response senza cambiare il modello di fiducia.

Il limite attuale della sicurezza AI: manca la verifica delle risposte

Nessuno di questi tre controlli autentica l’origine. Un router che si mantenga all’interno degli allowlist locali e sappia evitare pattern troppo evidenti può comunque alterare la semantica dei tool-call senza che il client abbia modo di accorgersene. La conclusione degli autori è esplicita: chiudere la falla richiede una busta firmata dal provider, un oggetto JSON canonicalizzato (nell’appendice C del paper ne è proposta una struttura ispirata a DKIM, RFC 6376, e alla canonicalizzazione JCS di RFC 8785) che contenga identità del provider, modello, contenuto, tool-call con argomenti nativi, nonce del client, finestra di validità e firma Ed25519. Nessun provider di tool-use e nemmeno la specifica MCP attuale espongono oggi un meccanismo simile.

Sicurezza informatica aziende: cosa fare subito

Fino a quando quel meccanismo non esisterà, la conseguenza operativa per CISO, CTO e team DevSecOps è immediata. Il trust boundary reale di un agente LLM non coincide con il router che l’utente ha scelto di configurare: coincide con il più debole router presente nell’intera catena a valle, con ogni credenziale precedentemente trapelata che qualcuno lungo quella catena stia ancora riutilizzando e con il livello di autonomia che il client ha lasciato attivo. Una sessione YOLO su un endpoint gratuito pescato in un gruppo Telegram non è un power user che sa quel che fa: è una superficie di attacco su cui, alla luce dei dati appena pubblicati, è già stato scritto abbastanza per non considerarla più teorica.

Sul piano delle policy aziendali, il paper suggerisce alcune scelte che difficilmente potranno essere rimandate a lungo. L’inventario degli endpoint LLM effettivamente usati da sviluppatori e agenti interni va fatto con lo stesso rigore con cui si inventariano i provider cloud, e non può fermarsi al router di primo livello: deve seguire, dove possibile, l’intera catena di relay.

Le modalità autonome dei coding agent richiedono un contenimento attivo, ovvero sandbox, devcontainer o macchine dedicate con accesso di rete limitato a una lista di host fidati; questo è del resto anche l’orientamento esplicitato da Anthropic nella propria documentazione «Safe YOLO» per Claude Code, che raccomanda l’uso di --dangerously-skip-permissions solo all’interno di container senza accesso a Internet. Le chiavi che transitano sui router non devono essere a lunga durata: sono token scoped a scadenza breve, ruotati su incidente e, dove il vendor lo supporta, emessi per singolo task.

E per i tool a più alto rischio, quelli che chiamano Bash, run_command , pip install , npm install , cargo add , un policy gate lato client con allowlist esplicita di domini e pacchetti è, pur con tutti i suoi limiti, un investimento dall’ottimo rapporto costo-beneficio rispetto alle alternative odierne.

Conclusione: la nuova frontiera degli attacchi AI

Il messaggio di fondo del lavoro di Liu e colleghi è che la supply chain degli agenti LLM non comincia al provider del modello e non finisce al client: passa per uno strato di intermediari che oggi il mercato tratta come trasporto trasparente e che, per come è fatto, non può esserlo. Renderlo verificabile è un problema di standard, non di buone pratiche.