AGENTS CRITICAL NEW

Checkpointers LangGraph : de l'injection SQL au RCE sur agents auto-hébergés

Check Point Research a enchaîné une injection SQL dans le checkpointer de LangGraph avec une désérialisation msgpack non sécurisée pour atteindre l'exécution de code à distance. Divulgué le 11 juin 2026 ; les trois CVE sont corrigées.

2026-06-17 // 7 min affects: langgraph, langgraph-checkpoint-sqlite, langgraph-checkpoint-redis

De quoi s’agit-il ?

Le 11 juin 2026, Check Point Research (Yarden Porat) a publié une analyse de LangGraph, le framework open source que LangChain propose pour les workflows d’agents multi-étapes — environ 46,5 millions de téléchargements mensuels sur PyPI. Il ne s’agit pas d’une astuce d’injection de prompt, mais d’une chaîne de vulnérabilités web classique logée dans un framework d’agents : une injection SQL dans la couche de persistance, enchaînée avec une désérialisation non sécurisée, aboutissant à l’exécution de code à distance (RCE) sur l’hôte.

Trois CVE ont été assignées, toutes désormais corrigées :

CVE-2025-67644 — injection SQL dans le checkpointer SQLite.
CVE-2026-28277 — désérialisation msgpack non sécurisée dans le chargeur de checkpoint.
CVE-2026-27022 — la même classe d’injection dans le checkpointer Redis.

La plateforme managée LangSmith Deployment (adossée à PostgreSQL) n’est pas affectée. L’exposition concerne spécifiquement les équipes qui auto-hébergent LangGraph avec le checkpointer SQLite ou Redis.

Comment ça marche

Un checkpointer est la mémoire de LangGraph : il enregistre l’état d’exécution de l’agent à chaque étape pour permettre une reprise ultérieure. Le point d’entrée vulnérable est l’API get_state_history(), qui appelle en interne la méthode list() du checkpointer et accepte un dictionnaire filter servant à interroger les métadonnées des checkpoints.

La faille réside dans la façon dont ce filtre est transformé en SQL. Le constructeur de prédicat de métadonnées interpole directement la clé du dictionnaire, contrôlée par l’attaquant, dans une expression json_extract(...) au lieu de la lier comme paramètre :

# conceptuel — la clé est interpolée, pas paramétrée
f"json_extract(CAST(metadata AS TEXT), '$.{query_key}') {operator}"

Si une application transmet une entrée utilisateur dans ce filter, l’attaquant contrôle la clé et peut s’échapper de la chaîne de chemin JSON pour injecter du SQL. La chaîne comporte alors deux étapes :

Étape 1 — injection SQL (CVE-2025-67644 / CVE-2026-27022)
  Injecter un UNION SELECT dans la clause WHERE pour que la requête
  retourne une ligne de checkpoint façonnée par l'attaquant, avec le
  BLOB `checkpoint` et son `type` réglés sur une valeur que le chargeur
  va désérialiser. [payload CAVIARDÉ]

Étape 2 — désérialisation non sécurisée (CVE-2026-28277)
  list() passe chaque ligne retournée à serde.loads_typed(). Pour le
  type "msgpack", l'ext_hook de LangGraph reconstruit des objets
  arbitraires :
      importlib.import_module(mod), getattr(name)(arg)
  Une extension forgée se résout en (os, system, <commande>) → RCE.

Ce qui rend cette faille plus grave qu’une injection SQL d’école, c’est la seconde étape. Le gestionnaire d’extensions msgpack avait été conçu pour reconstruire des objets Python personnalisés ; des octets contrôlés par l’attaquant deviennent donc os.system(<commande>). Aucune des deux failles n’est inédite — le UNION SELECT et la désérialisation non sécurisée ont des décennies d’existence. La nouveauté, c’est qu’elles se situent sur le chemin d’exécution d’un agent autonome qui détient des identifiants de production. Aucun payload n’est reproduit ici ; la référence est l’article de Check Point, et les bugs sont corrigés.

Pourquoi c’est important

Un serveur LangGraph compromis n’est pas un incident circonscrit à une seule session, comme l’est souvent une injection de prompt. Selon Check Point, l’exécution de code complète sur cet hôte donne à l’attaquant les clés d’API LLM de l’agent (facturables directement), l’intégralité de son historique de conversations, toutes les données CRM/helpdesk/facturation et PII connectées, ainsi qu’un point de pivot vers les systèmes internes avec les accès dont l’agent héritait.

La leçon de fond est celle sur laquelle LLM Hacking revient régulièrement : les frameworks d’agents héritent de toutes les classes de vulnérabilités classiques, et les amplifient. Une injection SQL qui serait un bug d’accès aux données de gravité moyenne dans une application CRUD devient critique lorsque le même chemin de code désérialise aussi des données et s’exécute au sein d’une automatisation privilégiée. LangGraph auto-hébergé est par ailleurs livré sans authentification intégrée : une instance exposée élargit encore le rayon d’impact.

Défenses

Les vulnérabilités sont corrigées — la mise à jour est la première étape, et la plus importante.

Mettez à jour sans attendre. Passez à langgraph-checkpoint-sqlite 3.0.1+ (CVE-2025-67644), langgraph 1.0.10+ / langgraph-checkpoint 4.0.1+ (CVE-2026-28277) et langgraph-checkpoint-redis 1.0.2+ (CVE-2026-27022). Toute version inférieure doit être traitée en priorité.
Ne transmettez jamais d’entrée utilisateur aux filtres de get_state_history(). Auditez votre application pour repérer tout chemin où des données de requête atteignent le filter du checkpointer. Liez les valeurs comme paramètres ; restreignez les clés filtrables via une liste d’autorisation.
Authentifiez le serveur LangGraph. LangGraph auto-hébergé n’a pas d’authentification propre. Placez un reverse proxy ou une API gateway devant lui et tenez-le hors des réseaux non fiables — traitez-le comme un service strictement interne.
Traitez le runtime de l’agent comme une identité privilégiée. Il détient des clés d’API, des identifiants de base de données et des jetons SaaS ; un hôte d’agent compromis mérite le même niveau de réponse qu’un compte privilégié compromis.
Moindre privilège et secrets éphémères. Réduisez chaque identifiant détenu par l’agent, préférez le courtage de secrets aux clés statiques de longue durée, et segmentez la couche de persistance (SQLite/Redis) du reste du réseau.
Faites du red team sur la chaîne, pas sur les pièces. La gravité provient de l’enchaînement, et les scanners individuels détectent les bugs isolés en manquant la combinaison. Exercez la pile agentique de façon adverse, de bout en bout.

Statut

Élément	Référence	Date	Notes
Divulgation à LangChain	Check Point Research	2025-11-19	Trois problèmes signalés
CVE-2025-67644 (SQLi SQLite)	langgraph-checkpoint-sqlite 3.0.1	2025-12-10	Le correctif brise la chaîne RCE
CVE-2026-27022 (SQLi Redis)	langgraph-checkpoint-redis 1.0.2	2026-02-20	Même classe d’injection
CVE-2026-28277 (déser. msgpack)	langgraph-checkpoint 4.0.1 / langgraph 1.0.10	2026-03-05	Désérialisation → RCE
Publication	Check Point Research / Check Point Blog	2026-06-11	Divulgation coordonnée terminée
LangSmith Deployment managé	LangChain	—	Backend PostgreSQL, non affecté

Le bon cadrage n’est pas « LangGraph n’est pas sûr ». C’est que les frameworks d’agents avec état présentent une vaste surface d’infrastructure encore peu testée, et que la couche de persistance — la mémoire de l’agent — en fait partie. Mettez à jour, authentifiez, et cessez de considérer comme fiables les données qui proviennent « de l’intérieur » du framework.