LangGraph RCE Chain: Patch Self-Hosted AI Agent Checkpointers

LangGraph users running self-hosted AI agent workflows should patch three checkpointer vulnerabilities after Check Point Research showed how flaws in the persistence layer can be chained from query injection to remote code execution in specific deployments.^[1]

When agent memory accepts forged files, the patch wrench should not stay in the toolbox.

The issue matters because LangGraph checkpointers store an agent graph’s state so workflows can resume later. In exposed applications, that memory layer may include prompts, tool results, thread metadata, and operational context. Check Point’s public analysis says the risky path appears when a self-hosted application uses SQLite or Redis checkpointers and exposes get_state_history() or similar checkpoint history access with a user-controlled filter.^[1]

Who should patch first

The highest-priority group is teams that built public or partner-facing LangGraph services, especially where users can influence metadata filters, conversation IDs, agent state lookup, or workflow history views. This is not the same as saying every LangGraph installation is instantly exploitable; the dangerous condition is the combination of a vulnerable checkpointer, reachable history/query functionality, and attacker-controlled filter input.

For Python deployments, Check Point describes an RCE chain that begins with CVE-2025-67644, a SQL injection issue in langgraph-checkpoint-sqlite. That injection can be used to place attacker-controlled checkpoint data into SQLite. The chain then relies on CVE-2026-28277, an unsafe msgpack deserialization issue that can execute code when crafted checkpoint data is loaded.^[1]

GitHub’s advisory lists langgraph-checkpoint-sqlite versions before 3.0.1 as affected by CVE-2025-67644, while the unsafe msgpack advisory lists langgraph versions through 1.0.9 as affected and 1.0.10 as patched.^[2][3] A separate JavaScript-side Redis issue, CVE-2026-27022, affects @langchain/langgraph-checkpoint-redis versions before 1.0.2.^[4]

Administrators should update vulnerable packages, redeploy affected services, and then review whether external users can pass raw filter keys or values into checkpoint history functions. It is also worth rotating secrets if a vulnerable self-hosted agent handled sensitive tool output or credentials, because checkpoint stores can become a record of what the agent saw and did.

The practical triage is straightforward: inventory LangGraph apps, identify SQLite or Redis checkpointer use, search code for history or checkpoint listing endpoints, and confirm that user-controlled filter dictionaries are validated before reaching the checkpointer. The same pattern showed up recently in other AI workflow risks, including Langflow server exposure, AI coding-tool abuse in the Miasma campaign, and developer-secret theft through poisoned tooling.

For teams building agentic applications, the lesson is broader than one package update. Agent memory is application state, and application state should be treated like a database boundary: validate inputs, avoid unsafe deserialization, isolate backing stores, and log checkpoint reads that should not normally be reachable from the public internet.

References

1. Check Point Research, “From SQLi to RCE – Exploiting LangGraph’s Checkpointer”, published June 11, 2026.
2. GitHub Advisory Database, “LangGraph’s SQLite is vulnerable to SQL injection via metadata filter key in SQLite checkpointer list method”, CVE-2025-67644.
3. GitHub Advisory Database, “LangGraph checkpoint loading has unsafe msgpack deserialization”, CVE-2026-28277.
4. GitHub Advisory Database, “RediSearch Query Injection in @langchain/langgraph-checkpoint-redis”, CVE-2026-27022.
5. The Hacker News, “LangGraph Flaw Chain Exposes Self-Hosted AI Agents to Remote Code Execution”, published June 12, 2026.