LangGraph RCE: Patch Your AI Agent Checkpointers Now

LangGraph’s checkpointer — the feature that gives your AI agents persistent memory across sessions — just became the attack surface. Three now-patched vulnerabilities disclosed on June 12 allow attackers to chain a SQL injection into full remote code execution on self-hosted LangGraph servers. If you’re running LangGraph on your own infrastructure with the SQLite or Redis checkpointer, read this before doing anything else today.

Two Flaws, One Very Bad Outcome

The vulnerability chain, discovered by Check Point Research security researcher Yarden Porat, combines two weaknesses in LangGraph’s SQLite checkpoint persistence layer.

CVE-2025-67644 (CVSS 7.3) — SQL injection in the SQLite checkpointer. The _metadata_predicate() function builds a SQL WHERE clause from metadata filter keys without sanitizing them. An attacker who controls the filter values passed to get_state_history() can inject a UNION clause, forcing the query to return an attacker-crafted row instead of real checkpoint data.

CVE-2026-28277 (CVSS 6.8) — Unsafe msgpack deserialization. After the injected SQL returns a fake checkpoint row, LangGraph deserializes it by calling loads_typed("msgpack", checkpoint). The deserialization hook, _msgpack_ext_hook(), reconstructs Python objects without validating their types. An attacker-crafted payload can reconstruct a Python object that calls os.system() on instantiation.

The full call chain:

get_state_history() → sqliteSaver.list() → UNION-injected SQL → loads_typed("msgpack") → _msgpack_ext_hook() → os.system()

A third flaw, CVE-2026-27022 (CVSS 6.5), introduces the same injection class into the Redis checkpointer via RediSearch query injection. It does not chain to RCE on its own, but it can bypass access controls on Redis-backed deployments.

What Attackers Actually Get

Remote code execution on a LangGraph server is worse than RCE on most other servers, because AI agent state is uniquely sensitive. LangGraph checkpoints accumulate everything the agent has ever touched: LLM API keys, full conversation and decision history, CRM credentials passed to tools, customer PII stored in agent state, and database connection strings. One compromised checkpointer and an attacker has the keys to your entire AI-powered stack.

Are You Affected?

The vulnerability chain only fires under specific conditions:

• You are running LangGraph self-hosted (LangSmith/LangGraph Platform uses PostgreSQL and is not affected)
• You are using the SQLite or Redis checkpointer backend
• User-controlled input reaches the filter parameters of get_state_history()

If you’re using the in-memory MemorySaver or managed LangGraph Platform, you’re not affected. That said, many teams that followed LangGraph tutorials defaulted to SQLite — it’s the path of least resistance. Assume you’re affected until you verify otherwise.

Patch Now: Three Packages

All three vulnerabilities are patched. Check the official GitHub security advisory and update immediately:

• langgraph → 1.0.10 or later
• langgraph-checkpoint-sqlite → 3.0.1 or later
• @langchain/langgraph-checkpoint-redis → 1.0.2 or later

pip install "langgraph>=1.0.10" "langgraph-checkpoint-sqlite>=3.0.1"

If you cannot patch immediately: stop exposing get_state_history() to user-controlled filter input, or validate and allowlist all metadata filter keys before they reach LangGraph. Running LangGraph processes under minimal OS permissions also limits damage post-RCE.

The Bigger Picture

This is the second major LangChain ecosystem security incident in six months. In December 2025, Porat discovered CVE-2025-68664 in LangChain Core — a serialization injection flaw with a CVSS score of 9.3 that earned a $4,000 bug bounty, the highest ever paid for a LangChain report. Six months later, another serialization issue in the same ecosystem.

The pattern is worth naming: AI agent frameworks are being deployed faster than they’re being hardened. Teams moved fast on LangGraph tutorials — reasonable, given how useful the framework is — but didn’t audit the persistence layer because it felt like plumbing. It is plumbing. Plumbing that serializes Python objects, executes SQL, and holds your API keys. That deserves the same security attention as any other database-backed service.