La risposta breve
Al Black Hat 2026 Check Point Research ha divulgato circa undici vulnerabilità nei framework per agenti IA su cui costruisce la maggior parte dei team — LangChain, LangGraph, CrewAI, AutoGen, Microsoft Agent Framework e Google ADK — e il titolo non è il prompt injection. È che questi framework lasciano regolarmente sfuggire i contenuti controllati dall'attaccante dal piano dati fino a raggiungere la logica affidabile: orchestrazione, memoria, routing, gestione dello stato e istruzioni di sistema. È così che un prompt di testo diventa una richiesta SSRF, un oggetto deserializzato, una scrittura di file abusiva o un comando shell.
Le classi di bug sono vecchie — deserializzazione non sicura, SSRF, path traversal, use-after-free — ma qui sono molto più pericolose perché i framework per agenti custodiscono chiavi API, credenziali di database e ampio accesso agli strumenti. Una falla del Microsoft Agent Framework è arrivata all'esecuzione di codice remoto tramite il caricamento di checkpoint non attendibili. Se la tua roadmap prevede agenti autonomi, la lezione pratica è netta: tratta il framework stesso come codice di gestione dell'input non attendibile, non come idraulica interna sicura.
Cosa ha davvero trovato Check Point
Presentando al Black Hat 2026, Check Point Research ha illustrato circa una dozzina di falle — diverse classificate come critiche — distribuite tra i framework che dominano lo sviluppo di agenti: LangChain, LangGraph, CrewAI, AutoGen, Microsoft Agent Framework e Google ADK. Nessuno dei singoli bug è esotico. Sono le stesse categorie che i team di sicurezza applicativa inseguono da due decenni: deserializzazione non sicura, server-side request forgery (SSRF), path traversal e use-after-free. Ciò che è cambiato è il contesto in cui ora vivono.
L'esempio più grave è arrivato dall'Agent Framework di Microsoft: un problema di deserializzazione non sicura in cui, innescato tramite prompt injection, l'agente caricava dati di checkpoint non attendibili e poteva essere indotto a eseguire codice dell'attaccante — un percorso di esecuzione di codice remoto stimato a gravità critica. Microsoft ha riconosciuto la segnalazione, ha pagato una ricompensa di 10.000 dollari e ha corretto la falla, pur non emettendo alcun CVE perché il framework non era ancora un prodotto generalmente disponibile quando Check Point l'ha segnalato. Altrove, i ricercatori hanno trovato un assistente di scrittura file di Google ADK raggiungibile via HTTP semplice per impostazione predefinita — una capacità dell'agente esposta alla rete senza alcuna autenticazione davanti. Per i team che già costruiscono flussi di lavoro con agenti IA, questi non sono casi limite; sono il cablaggio predefinito dei tutorial quick-start.
Perché i vecchi bug peggiorano dentro gli agenti
Per capire perché un familiare bug di deserializzazione è più spaventoso in un agente, guarda cosa custodisce davvero un framework per agenti. Non è un gestore di richieste stateless. Porta con sé le chiavi API del modello, le credenziali per i database e gli strumenti SaaS che l'agente può chiamare, la sua memoria conversazionale e spesso percorsi diretti verso le reti interne. Il lavoro precedente di Check Point su LangGraph ha reso concreta la posta in gioco: un server LangGraph compromesso esponeva simultaneamente chiavi API LLM, dati dei clienti, credenziali CRM, cronologia delle conversazioni e accesso alla rete interna. Il framework è un punto di strozzatura ad alta fiducia, quindi qualsiasi bug di esecuzione di codice al suo interno eredita tutta quella fiducia.
Il meccanismo che lo rende sfruttabile è il fallimento di confine a cui Check Point continua a tornare. In un'app normale, l'input dell'utente è dato e resta dato. In questi framework per agenti, il contenuto del prompt controllato dall'attaccante può sfuggire al piano dati e influenzare il flusso di controllo — quale strumento viene eseguito dopo, cosa viene deserializzato dalla memoria, quale URL l'agente recupera, su quale percorso scrive. È in sintesi la precedente catena del checkpointer di LangGraph: una SQL injection (CVE-2025-67644) ha seminato un checkpoint malevolo, e una deserializzazione msgpack non sicura (CVE-2026-28277) ha trasformato quel checkpoint in esecuzione di codice remoto, con una variante parallela di Redis injection (CVE-2026-27022). Le correzioni sono arrivate in langgraph 1.0.10 e successive, langgraph-checkpoint-sqlite 3.0.1+ e langgraph-checkpoint-redis 1.0.2+ — ma è la forma dell'attacco a generalizzarsi.
Perché è uno schema, non un singolo CVE
La ragione per trattarlo come un avvertimento architetturale anziché una nota di patch è che le stesse debolezze compaiono in modo indipendente in framework non correlati. Quando sei progetti diversi — da LangChain all'ADK di Google all'Agent Framework di Microsoft — fanno tutti trapelare il confine dati/controllo in modi simili, la causa non è un singolo manutentore distratto. È che l'intero ecosistema è cresciuto ottimizzando la capacità e la velocità di sviluppo, cablando insieme memoria, strumenti e routing con fiducia implicita, prima che qualcuno trattasse il livello di orchestrazione come un confine di sicurezza. Lo stesso team di sicurezza di Microsoft aveva segnalato la stessa classe di RCE “i prompt diventano shell” già nel 2026; la divulgazione di Check Point mostra che è sistemica.
Quell'inquadramento conta perché cambia dove investi le energie. Se credi che il prompt injection sia la malattia, riversi risorse nel filtraggio dell'input e nei prompt di guardrail — necessari, ma mai completi, perché un'iniezione determinata passerà. Se accetti che l'iniezione sia solo il furgone delle consegne e che il vero problema sia ciò che il framework fa con il payload, investi nei confini che contengono davvero i danni: non deserializzare mai stato non attendibile, autenticare ogni endpoint dell'agente e assegnare a ciascun agente le credenziali e la portata di rete più ristrette possibili. Il primo approccio prova a vincere una corsa impossibile alla sanificazione dell'input; il secondo limita il raggio d'impatto quando la corsa è persa.
Cosa significa per i team software statunitensi ed europei
La prima implicazione è che i framework per agenti rientrano ora nel perimetro della tua sicurezza applicativa, non in un contenitore separato di “esperimento IA”. I componenti che i team trattano come idraulica interna — checkpointer, memory store, router, tool loader — sono esattamente i percorsi di gestione dell'input che Check Point ha sfruttato. Meritano lo stesso threat modeling, il vincolo delle dipendenze e i penetration test e audit di sicurezza che già applichi al tuo livello web. Se il perimetro del tuo pen-test si ferma all'API gateway e non tocca mai il runtime dell'agente, sta testando il perimetro sbagliato.
La seconda è un punto di conformità che colpisce più duramente il lavoro regolamentato. Un agente in grado di leggere dati di produzione attraverso un framework che porta credenziali non ristrette è una lacuna di controllo, e un bug di esecuzione di codice remoto in quel framework è un incidente segnalabile in attesa di accadere. Per i team FinTech e HealthTech, i controlli che poni intorno ai framework per agenti — identità con privilegio minimo, allowlist di egress, deserializzazione in sandbox, una pista di audit delle chiamate agli strumenti — sono anche l'evidenza che gli auditor si aspettano ai sensi di SOC 2, DORA e dell'EU AI Act. Documentarli una sola volta serve sia alla sicurezza sia al regolatore.
La terza è disciplina architetturale che costa poco se la fai presto e molto se la fai tardi. Assegna a ogni agente le proprie credenziali con ambito ristretto e privilegio minimo invece di una chiave master condivisa, così che un agente dirottato non possa raggiungere l'intero patrimonio. Poni una allowlist di egress davanti alle chiamate agli strumenti degli agenti affinché un SSRF non possa pivotare verso i servizi interni. E non caricare mai checkpoint, memoria o stato serializzato da una fonte che non controlli completamente. I team che integrano questi vincoli nel livello piattaforma e DevOps fin dall'inizio assorbono il prossimo CVE di framework come un aggiornamento di routine; i team che li saltano ereditano una rete non tracciabile e sovra-privilegiata che è costosa da districare.
Cosa fare ora
Non devi cambiare framework questo trimestre. Devi smettere di trattare il runtime dell'agente come codice interno affidabile. Ecco la versione operativa.
- Inventaria e vincola i tuoi framework. Elenca ogni framework per agenti e versione in produzione e aggiorna alle release con patch (per LangGraph, ciò significa langgraph 1.0.10+, checkpoint-sqlite 3.0.1+, checkpoint-redis 1.0.2+).
- Iscriviti agli avvisi di sicurezza di ciascun framework. Tratta i CVE dei framework come tratti le patch del runtime e del sistema operativo, con un responsabile e uno SLA.
- Non deserializzare mai stato non attendibile. Checkpoint, memoria e oggetti serializzati da qualsiasi fonte che non controlli sono rischi di esecuzione di codice; convalidali o isolali in sandbox.
- Autentica ogni endpoint dell'agente. Nessuna capacità dell'agente — scrittori di file, tool server, route di amministrazione — dovrebbe essere raggiungibile via HTTP semplice senza autenticazione.
- Limita credenziali ed egress. Assegna a ogni agente chiavi con privilegio minimo e una allowlist in uscita, così che un'iniezione non possa pivotare verso l'intera rete.
- Aggiungi gli agenti ai tuoi test di sicurezza. Porta il runtime dell'agente nel threat modeling e nel perimetro del pen-test, e mantieni una pista di audit delle chiamate agli strumenti per SOC 2, DORA e l'EU AI Act.
Nulla di tutto ciò è una condanna di LangChain, CrewAI o degli altri — sono strumenti mainstream che vale la pena usare. La lezione duratura è architetturale: man mano che gli agenti passano dal rispondere all'agire, il framework che li cabla insieme è ormai codice critico per la sicurezza, e i team che lo modellano oggi come non attendibile spenderanno molto meno per ripulire dopo la prossima divulgazione.
Domande frequenti
Che cosa ha divulgato Check Point Research al Black Hat 2026?
Check Point Research ha divulgato circa una dozzina di vulnerabilità (intorno a 11) nei framework per agenti IA più diffusi, tra cui LangChain, LangGraph, CrewAI, AutoGen, Microsoft Agent Framework e Google ADK. Le falle appartengono a classi di bug software classiche — deserializzazione non sicura, SSRF, path traversal e use-after-free — che diventano molto più pericolose all'interno di framework che custodiscono chiavi API, credenziali e accesso ai dati. Un problema del Microsoft Agent Framework consentiva l'esecuzione di codice remoto tramite il caricamento di checkpoint non attendibili (CVSS stimato 9.8); Microsoft ha pagato una ricompensa di 10.000 dollari e l'ha corretto, ma non ha emesso alcun CVE perché il framework non era un prodotto generalmente disponibile al momento della divulgazione. Un assistente di scrittura file di Google ADK era raggiungibile via HTTP per impostazione predefinita.
È la stessa cosa del prompt injection?
No. Il punto centrale di Check Point è che il prompt injection è solo il meccanismo di consegna. La vera vulnerabilità è ciò che il framework fa con il contenuto iniettato: invece di mantenere il testo controllato dall'attaccante confinato nel piano dati, i framework spesso lo lasciano fluire nella logica affidabile — orchestrazione, memoria, routing, gestione dello stato e istruzioni di sistema. È questo che trasforma un prompt di testo in una richiesta SSRF, un oggetto deserializzato, una scrittura di file o un comando shell. Il bug vive nel middleware, non nel modello.
Quali framework per agenti IA sono interessati?
La divulgazione cita LangChain, LangGraph, CrewAI, AutoGen, Microsoft Agent Framework e Google ADK — i framework a cui la maggior parte dei team ricorre per primi. Una precedente catena di Check Point in LangGraph combinava una SQL injection (CVE-2025-67644), una deserializzazione msgpack non sicura che portava all'esecuzione di codice remoto (CVE-2026-28277) e una Redis injection (CVE-2026-27022) attraverso il checkpointer, corrette in langgraph 1.0.10+, langgraph-checkpoint-sqlite 3.0.1+ e langgraph-checkpoint-redis 1.0.2+. La storia è lo schema, non una singola libreria: le stesse debolezze si ripresentano in tutto l'ecosistema.
Dobbiamo smettere di usare LangChain, CrewAI o AutoGen?
No. Sono framework mainstream, attivamente mantenuti, e la mossa responsabile è applicare le patch, non rimuoverli. Aggiorna alle release corrette, iscriviti agli avvisi di sicurezza di ciascun framework e tratta il framework stesso come superficie di attacco: non caricare mai checkpoint, memoria o stato serializzato da fonti non attendibili, non esporre endpoint HTTP degli agenti senza autenticazione e poni le chiamate agli strumenti degli agenti dietro controlli di egress. L'obiettivo è smettere di trattare il livello di orchestrazione come idraulica interna affidabile.
Cosa dovrebbero fare ora i team di ingegneria?
Inventaria ogni framework per agenti e versione in produzione e vincolali alle release con patch. Modella i componenti stessi del framework — memory store, checkpointer, router, tool loader — come percorsi di input non attendibili e convalida o isola in sandbox tutto ciò che viene deserializzato. Assegna agli agenti credenziali con privilegio minimo e allowlist per l'egress di rete affinché un agente compromesso non possa raggiungere l'intero patrimonio. Aggiungi questi percorsi al perimetro dei tuoi test di sicurezza applicativa e di penetration testing. Per il lavoro regolamentato nel FinTech e nell'HealthTech, documenta i controlli come evidenza per SOC 2, DORA e l'EU AI Act.
Fonti
The Register — Prompt injection isn't the bug, AI agent frameworks are
Check Point Blog — When your AI agent's memory becomes a security liability
Check Point Research — From SQLi to RCE: exploiting LangGraph's checkpointer
Microsoft Security Blog — When prompts become shells: RCE vulnerabilities in AI agent frameworks