Quando i prompt diventano shell: vulnerabilità RCE negli AI agent framework

Gli agenti AI hanno cambiato radicalmente il modello di minaccia delle applicazioni basate su LLM. Finché un modello si limita a generare testo, le vulnerabilità rimangono nel dominio del contenuto. Ma non appena lo si dota di plugin (o tool) — lettura di file, query su database, esecuzione di script — il perimetro si espande. Una prompt injection non è più un problema di risposta inappropriata: può diventare un primitivo di esecuzione di codice arbitrario.

Il team di Microsoft Defender Security Research ha pubblicato un’analisi dettagliata di due vulnerabilità critiche scoperte in Semantic Kernel, il framework open source di Microsoft per la costruzione di agenti AI. Entrambe le vulnerabilità — già corrette — avrebbero consentito a un attaccante di ottenere RCE (Remote Code Execution) sul sistema che eseguiva l’agente, partendo semplicemente da un prompt malevolo.

Il problema di fondo: i framework AI si fidano troppo dell’output del modello

I framework come Semantic Kernel, LangChain e CrewAI agiscono come “sistema operativo” per gli agenti AI: astraggono l’orchestrazione del modello, gestiscono il routing verso i plugin e traducono il linguaggio naturale in chiamate a funzione strutturate. Questa convenienza ha un costo nascosto: ogni vulnerabilità nel modo in cui il framework mappa l’output del modello verso i tool di sistema porta un rischio sistemico.

Il modello AI stesso non è il problema — si comporta esattamente come progettato, parsando il linguaggio naturale in schemi di tool calling. Il problema sta nel fatto che il framework e i tool si fidano ciecamente dei dati così ottenuti.

CVE-2026-26030: In-Memory Vector Store e la pericolosità di eval()

La prima vulnerabilità riguarda il Search Plugin di Semantic Kernel quando usa l’In-Memory Vector Store con la configurazione predefinita.

Lo scenario di attacco richiede due condizioni:

1. L’attaccante deve avere un vettore di prompt injection — ovvero la capacità di influenzare gli input dell’agente
2. L’agente deve usare il Search Plugin con l’In-Memory Vector Store come backend

Radice tecnica del problema

La funzione di filtro predefinita dell’In-Memory Vector Store è implementata come espressione lambda Python eseguita tramite eval(). Per una ricerca tipica come “Find hotels in Paris”, il filtro generato è:

new_filter = "lambda x: x.city == 'Paris'"

Il parametro kwargs[param.name] — il valore di city — è controllato dall’output del modello AI, senza alcuna sanitizzazione. È un classico injection sink. Chiudendo la stringa e aggiungendo codice Python arbitrario, l’attaccante può trasformare una semplice query in payload eseguibile.

Il tentativo di mitigazione con blocklist — e il suo fallimento

I developer di Semantic Kernel avevano anticipato il rischio e implementato una blocklist che parsava il filtro in un Abstract Syntax Tree (AST) prima dell’esecuzione. Il validator:

• Permetteva solo espressioni lambda
• Rifiutava import e definizioni di classi
• Cercava identificatori pericolosi (eval, exec, open, __import__…)
• Eseguiva il codice in un ambiente ristretto con __builtins__ svuotati

I ricercatori hanno trovato un bypass completo. Il payload di exploit sfruttava quattro debolezze architetturali della blocklist:

1. Nomi mancanti nella blocklist: attributi come __name__, load_module, system e la classe BuiltinImporter non erano presenti nella lista nera
2. Il check strutturale passava: il payload era avvolto in una lambda valida, quindi isinstance(tree.body, ast.Lambda) restituiva True
3. __builtins__ vuoto era irrilevante: il payload partiva da tuple(), che esiste indipendentemente dall’ambiente dei builtin, e risaliva la gerarchia dei tipi Python per raggiungere funzionalità pericolose senza mai chiamare una builtin direttamente
4. Nessun controllo su ast.Subscript: anche se un nome bloccato fosse stato necessario, si sarebbe potuto accedere con notazione bracket (obj['__class__'] invece di obj.__class__), creando un nodo ast.Subscript ignorato dalla validazione

Il risultato pratico: un singolo prompt malevolo era sufficiente per lanciare calc.exe sul sistema che eseguiva l’agente, senza exploit del browser, allegati malevoli o memory corruption.

La lezione generale: le blocklist nei linguaggi dinamici sono fragili

Python (e linguaggi dinamici in generale) offre troppa flessibilità per essere gestita efficacemente con una lista nera. La gerarchia di classi del runtime, la riflessione, i dunders e le notazioni alternative rendono qualsiasi blocklist incompleta per definizione.

CVE-2026-25592: scrittura arbitraria di file tramite SessionsPythonPlugin

La seconda vulnerabilità riguarda il SessionsPythonPlugin, che permette agli agenti di eseguire codice Python in sessioni di Azure Container Apps. Il plugin accetta un nome di file come parametro controllato dall’LLM — senza validazione del percorso — e lo usa per scrivere file nel filesystem del container. Attraverso path traversal (es. ../../etc/cron.d/payload), un attaccante con accesso al vettore di prompt injection potrebbe scrivere file arbitrari in posizioni sensibili del sistema.

La mitigazione applicata da Semantic Kernel

Dopo la responsible disclosure al MSRC, il team di Semantic Kernel ha implementato una correzione multilivello per CVE-2026-26030, sostituendo la blocklist con un approccio allowlist a quattro strati:

1. Allowlist dei tipi AST: solo costrutti sicuri sono permessi — comparazioni, logica booleana, aritmetica, letterali
2. Allowlist delle chiamate a funzione: anche i nodi di chiamata AST permessi vengono verificati per assicurarsi che invochino solo funzioni sicure
3. Blocklist degli attributi pericolosi: traversata della gerarchia di classi bloccata esplicitamente (__class__, __subclasses__)
4. Restrizione sui nodi Name: solo il parametro della lambda (es. x) è accettabile come identificatore; riferimenti a os, eval, type e simili vengono rifiutati

Come sapere se si è vulnerabili

Si è esposti a CVE-2026-26030 se:

• Si usa il pacchetto Python semantic-kernel
• La versione del framework è precedente alla 1.39.4
• L’agente usa l’In-Memory Vector Store con funzionalità di filtro abilitata come backend per il Search Plugin

Per verificare la versione installata:

pip show semantic-kernel

Per aggiornare:

pip install --upgrade semantic-kernel

Raccomandazioni per gli sviluppatori di agenti AI

Questa ricerca offre lezioni importanti per chiunque stia costruendo applicazioni con agenti AI:

• Non trattare l’output del modello come dati fidati: qualsiasi valore che passa dal modello AI a un tool deve essere trattato come input non fidato, validato e sanitizzato come si farebbe con input da un utente esterno
• Preferire allowlist alle blocklist: nelle valutazioni di codice dinamico, le blocklist sono intrinsecamente incomplete. Un allowlist di costrutti permessi è molto più robusto
• Evitare eval() con input derivati dall’LLM: se il requisito è eseguire espressioni dinamiche, usare AST parsing con validazione rigorosa o, meglio, un motore di espressioni dedicato con capacità limitate
• Applicare il principio del minimo privilegio: i plugin degli agenti dovrebbero avere solo le autorizzazioni strettamente necessarie; un plugin che scrive file non dovrebbe mai avere accesso all’intero filesystem
• Monitorare i vettori di prompt injection: qualsiasi fonte esterna che l’agente legge (email, documenti, pagine web, risultati di ricerca) è un potenziale vettore di attacco
• Tenere aggiornati i framework: le vulnerabilità nei framework AI si stanno moltiplicando rapidamente; aggiornare regolarmente e seguire i bollettini di sicurezza dei vendor è essenziale

Un challenge per mettersi alla prova

Microsoft ha anche pubblicato un CTF challenge interattivo che permette di testare l’exploit su un agente Semantic Kernel di esempio in modo sicuro e controllato. È un ottimo modo per capire concretamente il vettore di attacco senza rischiare sistemi reali.

Conclusione

La transizione degli agenti AI da generatori di testo a sistemi che operano attivamente sull’infrastruttura richiede un cambio di mentalità nella sicurezza. Le vulnerabilità come CVE-2026-26030 e CVE-2026-25592 mostrano che i rischi sono reali e concreti: un prompt malevolo può diventare RCE. Aggiornare Semantic Kernel alla versione 1.39.4 o superiore è la priorità immediata; rivedere l’architettura dei propri agenti alla luce del principio di minimo privilegio è il passo successivo.

Microsoft ha annunciato una serie di ricerche simili su altri framework AI (LangChain, CrewAI e altri) — ulteriori pubblicazioni sono previste nelle prossime settimane.

Fonte: When prompts become shells: RCE vulnerabilities in AI agent frameworks — Microsoft Defender Security Research Team (7 maggio 2026)