LangGraph en contrôle pour trois vulnérabilités critiques qui peuvent permettre l'exécution de code à distance dans les installations auto-ménage

Les chercheurs en sécurité ont révélé trois vulnérabilités déjà corrigées dans LangGraph, le cadre open source développé par LangChain pour construire des agents d'IA d'état et multi-agents. Le plus critique est une chaîne d'échecs - l'injection SQL plus dangereuse desérialisation - qui, dans les installations auto-accueillées, peut permettre l'exécution de code à distance (ERC) si l'application expose certains paramètres et utilise les modules de persistance affectés.

Les défaillances identifiées comprennent CVE-2025-67644, une injection SQL dans l'implémentation SQLite du checkpointer qui permet de manipuler les consultations au moyen de filtres de métadonnées (touche langgraph-checkpoint-sqlite avant la version 3.0.1); CVE-2026-28277, une désactivation dangereuse de msgpack qui ouvre la porte à la reconstruction d'objets malveillants lors du transport de points de contrôle (touche longgraph avant la version 1.0.10); et CVE-2026-27022, une injection dans les consultations RediSearch qui peut éviter les contrôles d'accès dans @ langchain / langgraph-checkpoint-redis ( avant la version 1,0.1). Les résultats ont été attribués au chercheur Yarden Porat et publiés avec l'analyse de Check Point.

Le vecteur d'attaque le plus grave décrit par les chercheurs combine d'abord l'injection SQL pour renvoyer une rangée de points de contrôle contrefaits et force ensuite l'application à désactiver un msgpack BLOB contrôlé par l'attaquant, qui peut exécuter la charge utile intégrée. Cela dépend de la capacité du service à lire les points de contrôle des métadonnées (par exemple en obtenant l'historique _ état _ ()) et de la capacité de l'agresseur à influencer les filtres ou les données de l'entrepôt des points de contrôle..

Il est important de souligner que les configurations gérées par LangChain (LangSmith Deployment) ne sont pas affectées par ce scénario dans le modèle de menace décrit, car les environnements typiques hébergés ne permettent pas la manipulation directe du stockage des points de contrôle. Cependant, dans les propres déploiements (auto-organisés), l'exposition des paramètres sans authentification et le manque de protections dans la couche de persistance peuvent convertir des défaillances classiques telles que l'injection SQL en vecteurs critiques contre l'infrastructure IA.

D'un point de vue pratique, les opérateurs devraient prioriser l'application des mises à jour publiées par LangGraph et LangChain. Mettre à jour langgraph 1.0.10, langgraph-checkpoint-sqlite 3.0.1 et @ langchain / langgraph-checkpoint-redis 1,0.1(ou versions supérieures) ferme ces vulnérabilités connues. En outre, il convient d'examiner la télémétrie et le registre pour la détection rétrospective de questions ou de points de contrôle suspects et de vérifier l'accès à l'entrepôt de points de contrôle.

Au-delà du patch immédiat, l'atténuation compensatoire est essentielle : permettre une authentification et une autorisation robustes dans tout paramètre qui expose l'historique ou les points de contrôle; éviter les secrets statiques à long terme dans les périodes d'intervention des agents; segmenter les réseaux de façon à ce que les services de stockage (SQLite / Reis) ne soient pas accessibles dans les zones publiques; et appliquer le principe d'un privilège moindre aux agents, les traiter comme des identités privilégiées avec un accès restreint à des ressources spécifiques.

Au niveau du développement, il est essentiel de corriger la racine : utiliser des consultations paramétrées et une validation stricte des filtres avant de les intégrer dans les consultations SQL, introduire la signature ou l'intégrité des points de contrôle pour empêcher la charge de données manipulées, et remplacer ou atténuer l'extinction dangereuse par des formats sûrs ou des validations strictes. Pour la désérialisation des données binaires, il est recommandé de vérifier les schémas, d'utiliser des bibliothèques qui imposent des limites et, si possible, d'éviter l'exécution de code à partir d'objets reconstruits.

Les opérateurs qui ne peuvent pas se garer immédiatement devraient au moins désactiver ou protéger l'historique _ état _ du paramètre (), restreindre l'accès à la base de données et au service à partir de réseaux peu fiables, faire pivoter les identifiants et les clés, et établir une surveillance et des alertes sur les opérations inhabituelles dans la couche de persistance. Envisager l'utilisation d'environnements d'exécution isolés et l'interdiction de privilèges inutiles réduit l'impact d'une possible escalade.

Cette affaire remplace au premier plan que des vulnérabilités bien connues (injection SQL, désactivation dangereuse) chargent une nouvelle dimension lorsqu'elles se trouvent dans des cadres d'agents d'IA qui traitent des secrets, des références et des connexions à d'autres systèmes. Pour plus de contexte sur les attaques de désactivation et les bonnes pratiques contre l'injection SQL, voir le guide OWASP sur la désactivation dangereuse et la documentation OWASP sur l'injection SQL. Pour l'information et la diffusion de la découverte et des corrections, vous pouvez consulter l'avis des chercheurs et le dépôt LangChain dans GitHub: Recherche au point de contrôle, OWASP, GitHub - LangChain.