LangGraph checkpointers: from SQL injection to RCE on self-hosted agents

What is this?

On June 11, 2026, Check Point Research (Yarden Porat) published an analysis of LangGraph, the open-source framework LangChain ships for stateful, multi-agent workflows — roughly 46.5 million monthly downloads on PyPI. The finding is not a prompt-injection trick. It is a classic web-app vulnerability chain living inside an agent framework: a SQL injection in the persistence layer chained with an unsafe deserialization, ending in remote code execution on the host.

Three CVEs were assigned, all now patched:

• CVE-2025-67644 — SQL injection in the SQLite checkpointer.
• CVE-2026-28277 — unsafe msgpack deserialization in the checkpoint loader.
• CVE-2026-27022 — the same injection class in the Redis checkpointer.

LangChain’s managed LangSmith Deployment (PostgreSQL-backed) is not affected. The exposure is specific to teams self-hosting LangGraph with the SQLite or Redis checkpointer.

How it works

A checkpointer is LangGraph’s memory: it stores the agent’s execution state at each step so it can be resumed. The vulnerable entry point is the get_state_history() API, which internally calls the checkpointer’s list() method and accepts a filter dictionary used to query checkpoint metadata.

The bug is in how the filter is turned into SQL. The metadata predicate builder interpolates the attacker-influenced dictionary key directly into a json_extract(...) expression instead of binding it as a parameter:

# conceptual — the key is interpolated, not parameterized
f"json_extract(CAST(metadata AS TEXT), '$.{query_key}') {operator}"

If an application forwards user input into that filter, an attacker controls the key and can break out of the JSON path string to inject SQL. From there the chain has two stages:

Stage 1 — SQL injection (CVE-2025-67644 / CVE-2026-27022)
  Inject a UNION SELECT into the WHERE clause so the query returns
  one attacker-shaped checkpoint row, with the `checkpoint` BLOB and
  its `type` set to a value the loader will deserialize. [payload REDACTED]

Stage 2 — unsafe deserialization (CVE-2026-28277)
  list() feeds each returned row to serde.loads_typed(). For the
  "msgpack" type, LangGraph's ext_hook reconstructs arbitrary objects:
      importlib.import_module(mod), getattr(name)(arg)
  A crafted extension resolves to (os, system, <command>) → RCE.

The reason this matters more than a textbook SQLi is the second stage. The msgpack extension handler was built to revive custom Python objects, so attacker-controlled bytes become os.system(<command>). Neither flaw is novel on its own — UNION SELECT and insecure deserialization are decades old. What is new is that they sit on the execution path of an autonomous agent that holds production credentials. No payload is reproduced here; the canonical write-up is Check Point’s, and the bugs are fixed.

Why it matters

A compromised LangGraph server is not a contained single-session incident the way a prompt injection usually is. Per Check Point, full code execution on that host hands an attacker the agent’s LLM API keys (directly billable), its entire conversation history, any connected CRM/helpdesk/billing data and PII, and a pivot into internal systems with whatever access the agent inherited.

The broader lesson is the one LLM Hacking keeps returning to: agent frameworks inherit every classic vulnerability class, and amplify it. A SQL injection that would be a medium-severity data-access bug in a CRUD app becomes critical when the same code path also deserializes data and runs inside a privileged automation. Self-hosted LangGraph also ships without built-in authentication, so an exposed instance widens the blast radius further.

Defenses

The vulnerabilities are patched — upgrading is the first and most important step.

1. Patch now. Update to langgraph-checkpoint-sqlite 3.0.1+ (CVE-2025-67644), langgraph 1.0.10+ / langgraph-checkpoint 4.0.1+ (CVE-2026-28277), and langgraph-checkpoint-redis 1.0.2+ (CVE-2026-27022). If you run any version below these, treat it as the immediate priority.
2. Never pass user input into get_state_history() filters. Audit your application for any path where request data reaches the checkpointer’s filter. Bind values as parameters; allowlist filterable keys.
3. Authenticate the LangGraph server. Self-hosted LangGraph has no auth of its own. Put a reverse proxy or API gateway in front of it and keep it off untrusted networks — treat it as internal-only.
4. Treat the agent runtime as a privileged identity. It holds API keys, DB credentials and SaaS tokens; a compromised agent host deserves the same response severity as a compromised privileged account.
5. Least privilege and short-lived secrets. Minimize each credential the agent holds, prefer credential brokering over long-lived static keys, and segment the persistence layer (SQLite/Redis) from the rest of the network.
6. Red-team the chain, not the parts. The severity came from chaining, and individual scanners catch individual bugs while missing the combination. Exercise the agentic stack adversarially, end to end.

Status

Item	Reference	Date	Notes
Disclosure to LangChain	Check Point Research	2025-11-19	All three issues reported
CVE-2025-67644 (SQLite SQLi)	langgraph-checkpoint-sqlite 3.0.1	2025-12-10	Fix breaks the RCE chain
CVE-2026-27022 (Redis SQLi)	langgraph-checkpoint-redis 1.0.2	2026-02-20	Same injection class
CVE-2026-28277 (msgpack deser)	langgraph-checkpoint 4.0.1 / langgraph 1.0.10	2026-03-05	Deserialization → RCE
Public write-up	Check Point Research / Check Point Blog	2026-06-11	Coordinated disclosure complete
Managed LangSmith Deployment	LangChain	—	PostgreSQL backend, not affected

The right framing is not “LangGraph is unsafe.” It is that stateful agent frameworks have a large, under-tested infrastructure surface, and the persistence layer — the agent’s memory — is part of that surface. Patch, authenticate, and stop treating data that originates “inside” the framework as trusted.