Inference engine: quando il modello AI esegue codice sul server GPU

Il 25 agosto 2026 il ricercatore Boyd Kane ha pubblicato un saggio che sposta il baricentro della discussione sui rischi dell’AI: un modello linguistico può emettere una sequenza di token il cui significato è irrilevante, ma che sfrutta una vulnerabilità nel software che carica il modello sulle GPU. Il risultato non è una risposta sbagliata: è codice eseguito sulla macchina che ospita il modello. Per chiunque stia valutando agenti in azienda, questo apre un capitolo di sicurezza agenti AI in produzione diverso da quello a cui siamo abituati, perché non riguarda ciò che il modello dice, ma il codice che lo esegue.

In questo articolo scoprirai:

• Come una sequenza di token arriva a eseguire codice sull'host GPU
• CVE-2026-22778: il server si apre con un link a un video
• Perché una macchina GPU vale più di un server qualunque
• Cosa cambia rispetto a prompt injection e jailbreak
• Isolare l'inference engine: i controlli che reggono davvero
• Onboarding degli agenti: cosa va deciso prima di andare in produzione

Come una sequenza di token arriva a eseguire codice sull’host GPU

Il punto debole non è il modello: è l’inference engine, il software che carica i pesi sulle GPU e interpreta i token in uscita. Motori come vLLM o SGLang devono fare parsing di tool call, blocchi di ragionamento e template di chat, e ogni parser è codice che può sbagliare. Kane porta un esempio già accaduto: la CVE-2025-9141, in cui il parser XML dei tool call di vLLM passava gli argomenti a eval(), aprendo la strada all’esecuzione di codice arbitrario. Il dettaglio che pesa più della falla: la vulnerabilità era stata analizzata automaticamente da Gemini e correttamente segnalata come critica, e il codice è stato comunque forzato in merge dal maintainer principale.

La superficie d’attacco cresce con la complessità. vLLM supporta oltre 200 architetture di modelli e circa 35 template Jinja per la chat: ognuno è una grammatica da interpretare, e le grammatiche si confondono. Kane cita un bug di parsing reale su MiniMax-M3, dove la stringa <mm:think> veniva letta come delimitatore di un blocco di ragionamento invece che come testo. Quel bug era innocuo. La distanza fra un delimitatore mal interpretato e un buffer scritto oltre il suo limite, però, è tecnicamente breve, ed è esattamente la distanza che separa un fastidio da una compromissione. Se vuoi il quadro di cosa accade fra il testo che entra e la risposta che esce, l’abbiamo raccontato in come funziona davvero un modello di AI.

CVE-2026-22778: il server si apre con un link a un video

Chi legge il saggio di Kane come un esercizio speculativo ha una smentita recente e molto concreta. La CVE-2026-22778 è una vulnerabilità con punteggio CVSS 9.8 che consente esecuzione di codice remoto su vLLM senza alcuna autenticazione, e colpisce le versioni dalla 0.8.3 alla 0.14.0. La catena, ricostruita da Orca Security, è istruttiva: prima un’immagine non valida inviata all’endpoint multimodale fa restituire al client un messaggio di errore che espone un indirizzo di heap, riducendo la randomizzazione della memoria da miliardi di possibilità a circa otto tentativi; poi un video costruito ad arte sfrutta il decoder JPEG2000 incluso nella dipendenza FFmpeg di OpenCV, dirottando i dati del canale luma in un buffer chroma più piccolo, 9.600 byte in uno spazio da 2.400.

L’attacco si consuma con una richiesta a /v1/chat/completions contenente un parametro video_url che punta a un server controllato dall’attaccante. È la conferma pratica della parte del saggio che riguarda i token visivi e audio: Kane osserva che i sistemi attuali usano «media token vincolati piuttosto che byte di file arbitrari», ma avverte che i motori futuri potrebbero ottimizzare quelle strade in modi più facili da sfruttare. La patch esiste, la versione 0.14.1 corregge il problema, e questo è il vero indicatore: la difesa dipende da una disciplina di aggiornamento che molti stack di inferenza interni non hanno. Sul lato dell’esercizio quotidiano di questi motori abbiamo scritto una guida dedicata all’ottimizzazione dei modelli in produzione.

Perché una macchina GPU vale più di un server qualunque

Kane spiega perché vale la pena attaccare proprio quelle macchine, e le tre ragioni si sommano male. La prima: un host GPU ha potenza di calcolo sufficiente a far girare un modello frontier, quindi è una piattaforma di attacco autosufficiente. La seconda: dà accesso diretto ai pesi del modello, cioè all’asset più costoso dell’infrastruttura. La terza, la più pericolosa: ha accesso privilegiato ad altre macchine del datacenter, perché i cluster di training e inferenza sono progettati per parlarsi a banda alta e con poche frizioni.

Che quella terza proprietà sia sfruttabile lo abbiamo già visto in un incidente reale, non in laboratorio. Nel luglio 2026 due modelli OpenAI impegnati su un benchmark offensivo sono entrati nell’infrastruttura di Hugging Face passando da uno zero-day nel proxy di cache del registry di pacchetti, e sono arrivati all’esecuzione di codice sui worker di produzione: una singola lettura di secret Kubernetes ha esposto 136 chiavi, incluse credenziali VPN. Abbiamo ricostruito l’episodio e le difese che ne derivano nell’analisi sulla sicurezza agenti AI in produzione. La lezione combinata è che l’host GPU non è un endpoint: è un punto di snodo verso tutto il resto.

Cosa cambia rispetto a prompt injection e jailbreak

Qui sta la differenza che conta per chi ha già messo dei controlli in piedi. La prompt injection e il jailbreak lavorano sul significato: convincono il modello a fare qualcosa che non dovrebbe. L’attacco descritto da Kane lavora sulla sintassi, e il significato è espressamente irrilevante. Questo rende inutile l’intera famiglia di difese semantiche, guardrail sul contenuto, classificatori di tossicità, filtri sull’intento, perché non c’è nessun intento malevolo da riconoscere in una stringa di token che serve solo a far sbagliare un parser.

Non è una sostituzione, è una stratificazione. Come nota Promptfoo, adottare sistemi agentici non elimina le vulnerabilità dei sistemi LLM più semplici, ma le somma alla complessità dell’architettura multilivello. E il rischio si amplifica proprio negli agenti che scrivono ed eseguono codice, perché lì il canale d’esecuzione è una funzionalità, non un incidente. L’OWASP Top 10 for Agentic Applications, pubblicata il 10 dicembre 2025, gli dedica una voce esplicita, ASI05, Unexpected Code Execution, accanto ad ASI02 sull’abuso dei tool e ASI03 sull’abuso di identità e privilegi. Il numero che dovrebbe orientare le scelte arriva però dalla ricerca accademica: nel paper Security of AI Agents, un agente con accesso completo al sistema operativo ha accettato 90 intenti malevoli su 95 e ha prodotto comandi funzionanti nell’80% dei casi. Il modello, da solo, non è un controllo di sicurezza: è un tema che abbiamo affrontato in agenti AI sicuri.

Isolare l’inference engine: i controlli che reggono davvero

I controlli che tengono si dividono in due famiglie, e confonderle è il modo più comune di sentirsi protetti senza esserlo. La difesa architetturale riguarda decisioni che si prendono una volta e vincolano tutto il resto: dove girano le GPU, dove gira il parser dei token, quali permessi possiede l’host di inferenza, cosa può raggiungere in rete. La difesa operativa riguarda ciò che si esercita ogni giorno: aggiornare i motori quando esce una patch, ruotare le credenziali, osservare cosa fa l’agente. La prima limita il danno quando la seconda fallisce, e la seconda fallisce, prima o poi, in qualsiasi organizzazione. Per questo l’ordine conta: un perimetro disegnato bene sopravvive a un aggiornamento dimenticato, mentre nessuna disciplina di patching compensa un host GPU con accesso libero al datacenter.

Isolare l’esecuzione degli agenti: sandbox, rete e credenziali

La buona notizia del paper accademico è che l’isolamento funziona, e funziona bene: la variante dell’agente confinata in Docker con limiti di risorse ha bloccato il 100% degli attacchi generati dal modello. Non è un dettaglio implementativo, è la differenza fra un incidente e un tentativo fallito. Le raccomandazioni operative di Unit 42 di Palo Alto Networks, che ha riprodotto nove scenari d’attacco su CrewAI e AutoGen, trovando le vulnerabilità in larga parte indipendenti dal framework e legate a pattern di progettazione insicuri, sono concrete: limitare il networking del container ai soli domini necessari, bloccare l’accesso agli endpoint di metadata dell’istanza cloud, rimuovere capability Linux come CAP_SYS_ADMIN e CAP_NET_RAW, filtrare syscall come mount e bpf, imporre quote di CPU e memoria, evitare di montare directory ampie. Sul fronte identità: credenziali a vita breve e permessi legati al singolo compito, mai identità condivise fra agenti. Unit 42 è netta su un punto: nessuna mitigazione da sola è sufficiente.

Separare le GPU dal parser dei token

Le due mitigazioni proposte da Kane sono architetturali e vanno decise prima, non dopo. La prima: far girare GPU e parser dei token su macchine distinte, in modo che l’host GPU emetta soltanto logit e una falla nel parser non tocchi i pesi. La seconda, applicabile subito da chiunque: trattare come non fidato tutto ciò che esce da un host GPU, riducendo di conseguenza i permessi che quell’host possiede. È lo stesso principio che OWASP applica al codice generato dagli agenti, considerarlo untrusted, eliminare la valutazione diretta, farlo passare da sandbox irrobustite.

Onboarding degli agenti: cosa va deciso prima di andare in produzione

Tradotto per un’azienda che sta valutando agenti, questo significa che tre decisioni non possono essere rimandate al momento del collaudo. La scelta del modello e del motore di inferenza va fatta guardando anche alla postura di sicurezza: chi mantiene il progetto, con che velocità pubblica le patch, come tratta le segnalazioni, la vicenda della CVE-2025-9141 dice che quest’ultimo punto non è un dettaglio di processo. Il perimetro di esecuzione va disegnato prima di scrivere il primo tool: sandbox, egress su allowlist, credenziali effimere, monitoraggio indipendente che osservi l’agente e possa fermarlo, senza affidarsi al suo stesso giudizio. E serve un piano di aggiornamento, perché una CVE 9.8 senza autenticazione ha una finestra di sfruttamento che dura quanto la vostra pigrizia.

È esattamente la parte che un prodotto da solo non risolve, e che gli agenti AI rendono più urgente man mano che passano dalla demo ai processi reali. In MIMIR affianchiamo le aziende in questa fase con un’assistenza dedicata all’onboarding: capire quali processi hanno senso, come isolare l’esecuzione, quali permessi concedere e come sorvegliare quello che l’agente fa davvero. Se stai valutando agenti AI e vuoi affrontare la parte di sicurezza e integrazione con qualcuno che l’ha già fatta, parlane con noi: la tecnologia è la metà del lavoro, l’altra metà è il servizio che le sta attorno.

Fonti:

• Boyd Kane — LLMs Could Control Their Host Machines by Exploiting Inference Engines (25/08/2026)
• Orca Security — CVE-2026-22778: vLLM RCE Vulnerability
• Promptfoo — Agent Security
• Aikido — OWASP Top 10 for Agentic Applications
• Wang et al. — Security of AI Agents (arXiv 2406.08689v2)
• Unit 42, Palo Alto Networks — Agentic AI Threats