La réponse courte
À Black Hat 2026, Check Point Research a révélé une onzaine de vulnérabilités dans les frameworks d'agents IA sur lesquels la plupart des équipes bâtissent — LangChain, LangGraph, CrewAI, AutoGen, Microsoft Agent Framework et Google ADK — et le titre n'est pas l'injection de prompt. C'est que ces frameworks laissent régulièrement un contenu contrôlé par l'attaquant s'échapper du plan de données pour atteindre la logique de confiance : orchestration, mémoire, routage, gestion d'état et instructions système. C'est ainsi qu'un prompt textuel devient une requête SSRF, un objet désérialisé, une écriture de fichier malveillante ou une commande shell.
Les classes de bugs sont anciennes — désérialisation non sécurisée, SSRF, path traversal, use-after-free — mais elles sont bien plus dangereuses ici parce que les frameworks d'agents détiennent des clés d'API, des identifiants de bases de données et un large accès aux outils. Une faille de Microsoft Agent Framework a atteint l'exécution de code à distance via le chargement d'un checkpoint non fiable. Si votre feuille de route comporte des agents autonomes, la leçon pratique est directe : traitez le framework lui-même comme du code de traitement d'entrées non fiables, pas comme une tuyauterie interne sûre.
Ce que Check Point a réellement trouvé
Présentant à Black Hat 2026, Check Point Research a détaillé une douzaine de failles — plusieurs classées critiques — réparties sur les frameworks qui dominent le développement d'agents : LangChain, LangGraph, CrewAI, AutoGen, Microsoft Agent Framework et Google ADK. Aucun de ces bugs pris isolément n'est exotique. Ce sont les mêmes catégories que les équipes de sécurité applicative traquent depuis deux décennies : désérialisation non sécurisée, falsification de requête côté serveur (SSRF), path traversal et use-after-free. Ce qui a changé, c'est le contexte dans lequel ils vivent désormais.
L'exemple le plus grave venait du Microsoft Agent Framework : une désérialisation non sécurisée où, déclenché par une injection de prompt, l'agent chargeait des données de checkpoint non fiables et pouvait être orienté vers l'exécution de code de l'attaquant — un chemin d'exécution de code à distance estimé de gravité critique. Microsoft a reconnu le rapport, versé une prime de 10 000 dollars et corrigé la faille, sans toutefois émettre de CVE car le framework n'était pas encore un produit disponible au grand public lorsque Check Point l'a signalée. Ailleurs, les chercheurs ont trouvé un assistant d'écriture de fichiers de Google ADK accessible en HTTP clair par défaut — une capacité d'agent exposée sur le réseau sans aucune authentification devant elle. Pour les équipes qui construisent déjà des workflows d'agents IA, ce ne sont pas des cas limites ; c'est le câblage par défaut des tutoriels de démarrage rapide.
Pourquoi de vieux bugs s'aggravent dans les agents
Pour comprendre pourquoi un bug de désérialisation familier est plus effrayant dans un agent, regardez ce que détient réellement un framework d'agent. Ce n'est pas un gestionnaire de requêtes sans état. Il porte les clés d'API du modèle, les identifiants des bases de données et des outils SaaS que l'agent peut appeler, sa mémoire conversationnelle et souvent des chemins directs vers des réseaux internes. Les travaux antérieurs de Check Point sur LangGraph ont rendu l'enjeu concret : un serveur LangGraph compromis exposait d'un coup les clés d'API du LLM, des données clients, des identifiants CRM, l'historique des conversations et un accès au réseau interne. Le framework est un point de passage à haut niveau de confiance, si bien que tout bug d'exécution de code en son sein hérite de toute cette confiance.
Le mécanisme qui le rend exploitable est la rupture de frontière sur laquelle Check Point revient sans cesse. Dans une application normale, l'entrée utilisateur est une donnée et reste une donnée. Dans ces frameworks d'agents, le contenu de prompt contrôlé par l'attaquant peut glisser hors du plan de données et influencer le flux de contrôle — quel outil s'exécute ensuite, ce qui est désérialisé depuis la mémoire, quelle URL l'agent va chercher, dans quel chemin il écrit. C'est en résumé la chaîne antérieure du checkpointer de LangGraph : une injection SQL (CVE-2025-67644) a semé un checkpoint malveillant, et une désérialisation msgpack non sécurisée (CVE-2026-28277) a transformé ce checkpoint en exécution de code à distance, avec une variante d'injection Redis en parallèle (CVE-2026-27022). Les correctifs ont été livrés dans langgraph 1.0.10 et versions ultérieures, langgraph-checkpoint-sqlite 3.0.1+ et langgraph-checkpoint-redis 1.0.2+ — mais c'est la forme de l'attaque qui se généralise.
Pourquoi c'est un motif, pas un CVE isolé
La raison de traiter ceci comme un avertissement architectural plutôt qu'une note de correctif, c'est que les mêmes faiblesses apparaissent indépendamment dans des frameworks sans lien entre eux. Quand six projets différents — de LangChain à l'ADK de Google en passant par l'Agent Framework de Microsoft — laissent tous fuir la frontière données/contrôle de manière similaire, la cause n'est pas un mainteneur négligent. C'est que tout l'écosystème a grandi en optimisant la capacité et la vitesse de développement, en câblant mémoire, outils et routage avec une confiance implicite, avant que quiconque ne traite la couche d'orchestration comme une frontière de sécurité. L'équipe de sécurité de Microsoft avait elle-même signalé plus tôt en 2026 la même classe de RCE où « les prompts deviennent des shells » ; la divulgation de Check Point montre qu'elle est systémique.
Ce cadrage compte parce qu'il change l'endroit où vous dépensez vos efforts. Si vous croyez que l'injection de prompt est la maladie, vous investissez des ressources dans le filtrage des entrées et les prompts garde-fous — nécessaires, mais jamais suffisants, car une injection déterminée finira par passer. Si vous acceptez que l'injection n'est que le fourgon de livraison et que le vrai problème est ce que le framework fait de la charge utile, vous investissez dans les frontières qui contiennent réellement les dégâts : ne jamais désérialiser un état non fiable, authentifier chaque endpoint d'agent, et donner à chaque agent les identifiants et la portée réseau les plus étroits possibles. La première approche tente de gagner une course impossible à la désinfection des entrées ; la seconde limite le rayon d'impact lorsque la course est perdue.
Ce que cela signifie pour les équipes logicielles en France et en Europe
La première implication, c'est que les frameworks d'agents relèvent désormais de votre périmètre de sécurité applicative, et non d'un panier « expérimentation IA » séparé. Les composants que les équipes traitent comme de la tuyauterie interne — checkpointers, magasins de mémoire, routeurs, chargeurs d'outils — sont précisément les chemins de traitement d'entrées que Check Point a exploités. Ils méritent la même modélisation des menaces, le même épinglage des dépendances et les mêmes tests d'intrusion et audits de sécurité que vous appliquez déjà à votre couche web. Si votre périmètre de test d'intrusion s'arrête à la passerelle d'API et ne touche jamais le runtime de l'agent, il teste le mauvais périmètre.
La deuxième est un point de conformité qui frappe le plus durement les travaux réglementés. Un agent capable de lire des données de production via un framework porteur d'identifiants non restreints est une lacune de contrôle, et un bug d'exécution de code à distance dans ce framework est un incident déclarable qui ne demande qu'à survenir. Pour les équipes FinTech et HealthTech, les contrôles que vous placez autour des frameworks d'agents — identités au moindre privilège, listes d'autorisation de trafic sortant, désérialisation en bac à sable, piste d'audit des appels d'outils — sont aussi les preuves qu'attendent les auditeurs sous SOC 2, DORA et le règlement européen sur l'IA (AI Act). En France, un agent qui traite des données personnelles engage aussi vos obligations RGPD sous la CNIL, tandis que les recommandations de l'ANSSI sur la sécurité des systèmes d'IA et la transposition de NIS2 poussent dans le même sens : documenter ces contrôles une fois sert à la fois la sécurité et le régulateur.
Ce que cela signifie pour le marché français. En France, la vague d'adoption des agents IA touche d'abord les secteurs les plus régulés — banque et FinTech, assurance, HealthTech, secteur public — où un framework porteur d'identifiants non cloisonnés se heurte directement au RGPD, aux recommandations de l'ANSSI et, pour les entités financières, à DORA. Une entreprise française qui déploie un agent capable de lire des données de production hérite non seulement d'un risque d'exécution de code à distance, mais aussi d'une obligation démontrable de maîtrise du traitement vis-à-vis de la CNIL. Le réflexe utile ici n'est pas d'attendre un CVE : c'est de cloisonner dès maintenant la couche d'orchestration et d'en tracer les appels d'outils comme preuve de conformité.
La troisième est une discipline architecturale qui coûte peu si vous l'appliquez tôt et beaucoup si vous l'appliquez tard. Donnez à chaque agent ses propres identifiants au moindre privilège plutôt qu'une clé maîtresse partagée, afin qu'un agent détourné ne puisse pas atteindre l'ensemble de votre parc. Placez une liste d'autorisation de trafic sortant devant les appels d'outils des agents pour qu'un SSRF ne puisse pas pivoter vers des services internes. Et ne chargez jamais de checkpoints, de mémoire ou d'état sérialisé depuis une source que vous ne contrôlez pas entièrement. Les équipes qui intègrent ces contraintes dans la couche plateforme et DevOps dès le départ absorbent le prochain CVE de framework comme une mise à jour de routine ; celles qui les négligent héritent d'un maillage sur-privilégié et intraçable, coûteux à démêler.
Que faire maintenant
Vous n'avez pas besoin de changer de framework ce trimestre. Vous devez cesser de traiter le runtime de l'agent comme du code interne de confiance. Voici la version livrable.
- Inventoriez et épinglez vos frameworks. Recensez chaque framework d'agent et sa version en production et mettez à jour vers les versions corrigées (pour LangGraph, cela signifie langgraph 1.0.10+, checkpoint-sqlite 3.0.1+, checkpoint-redis 1.0.2+).
- Abonnez-vous aux avis de sécurité de chaque framework. Traitez les CVE de frameworks comme vous traitez les correctifs de runtime et d'OS, avec un responsable et un SLA.
- Ne désérialisez jamais un état non fiable. Les checkpoints, la mémoire et les objets sérialisés provenant d'une source que vous ne contrôlez pas sont des risques d'exécution de code ; validez-les ou isolez-les.
- Authentifiez chaque endpoint d'agent. Aucune capacité d'agent — modules d'écriture de fichiers, serveurs d'outils, routes d'administration — ne devrait être accessible en HTTP clair sans authentification.
- Restreignez identifiants et trafic sortant. Donnez à chaque agent des clés au moindre privilège et une liste d'autorisation sortante pour qu'une injection ne puisse pas pivoter vers tout votre réseau.
- Ajoutez les agents à vos tests de sécurité. Intégrez le runtime des agents à la modélisation des menaces et au périmètre des tests d'intrusion, et conservez une piste d'audit des appels d'outils pour SOC 2, DORA et le règlement européen sur l'IA.
Rien de tout cela n'est un verdict contre LangChain, CrewAI ou les autres — ce sont des outils courants qui valent la peine d'être utilisés. L'enseignement durable est architectural : à mesure que les agents passent de la réponse à l'action, le framework qui les câble ensemble est désormais du code critique pour la sécurité, et les équipes qui le modélisent comme non fiable dès aujourd'hui dépenseront bien moins à nettoyer après la prochaine divulgation.
Foire aux questions
Qu'a révélé Check Point Research à Black Hat 2026 ?
Check Point Research a révélé une douzaine de vulnérabilités (une onzaine environ) dans les frameworks d'agents IA les plus utilisés, dont LangChain, LangGraph, CrewAI, AutoGen, Microsoft Agent Framework et Google ADK. Les failles relèvent de classes de bugs logiciels classiques — désérialisation non sécurisée, SSRF, path traversal et use-after-free — qui deviennent bien plus dangereuses au sein de frameworks détenant des clés d'API, des identifiants et des accès aux données. Une faille de Microsoft Agent Framework permettait l'exécution de code à distance via le chargement d'un checkpoint non fiable (CVSS estimé à 9,8) ; Microsoft a versé une prime de 10 000 dollars et l'a corrigée, mais n'a émis aucun CVE car le framework n'était pas un produit disponible au grand public au moment de la divulgation. Un assistant d'écriture de fichiers de Google ADK était accessible en HTTP par défaut.
Est-ce la même chose que l'injection de prompt ?
Non. Le point central de Check Point est que l'injection de prompt n'est que le vecteur de livraison. La vraie vulnérabilité tient à ce que le framework fait du contenu injecté : au lieu de confiner le texte contrôlé par l'attaquant au plan de données, les frameworks le laissent souvent atteindre la logique de confiance — orchestration, mémoire, routage, gestion d'état et instructions système. C'est ce qui transforme un prompt textuel en requête SSRF, en objet désérialisé, en écriture de fichier ou en commande shell. Le bug vit dans le middleware, pas dans le modèle.
Quels frameworks d'agents IA sont concernés ?
La divulgation nomme LangChain, LangGraph, CrewAI, AutoGen, Microsoft Agent Framework et Google ADK — les frameworks vers lesquels la plupart des équipes se tournent en premier. Une chaîne antérieure de Check Point dans LangGraph combinait une injection SQL (CVE-2025-67644), une désérialisation msgpack non sécurisée donnant une exécution de code à distance (CVE-2026-28277) et une injection Redis (CVE-2026-27022) via le checkpointer, corrigées dans langgraph 1.0.10+, langgraph-checkpoint-sqlite 3.0.1+ et langgraph-checkpoint-redis 1.0.2+. C'est le motif, et non une bibliothèque unique, qui compte : les mêmes faiblesses reviennent dans tout l'écosystème.
Faut-il cesser d'utiliser LangChain, CrewAI ou AutoGen ?
Non. Ce sont des frameworks courants, activement maintenus, et la démarche responsable consiste à corriger, pas à les arracher. Mettez à jour vers les versions corrigées, abonnez-vous aux avis de sécurité de chaque framework et traitez le framework lui-même comme une surface d'attaque : ne chargez jamais de checkpoints, de mémoire ou d'état sérialisé depuis des sources non fiables, n'exposez pas d'endpoints HTTP d'agents sans authentification et placez les appels d'outils des agents derrière des contrôles de trafic sortant. Le but est de cesser de traiter la couche d'orchestration comme une tuyauterie interne de confiance.
Que doivent faire les équipes d'ingénierie maintenant ?
Inventoriez chaque framework d'agent et sa version en production et épinglez-les sur des versions corrigées. Modélisez les composants propres au framework — magasins de mémoire, checkpointers, routeurs, chargeurs d'outils — comme des chemins d'entrée non fiables, et validez ou isolez tout ce qui est désérialisé. Donnez aux agents des identifiants au moindre privilège et des listes d'autorisation de trafic sortant afin qu'un agent détourné ne puisse pas atteindre l'ensemble de votre parc. Ajoutez ces chemins à votre périmètre de tests de sécurité applicative et de tests d'intrusion existant. Pour les travaux réglementés en FinTech et HealthTech, documentez les contrôles comme preuves pour SOC 2, DORA et le règlement européen sur l'IA.
Sources
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