Skip to content
AI Security Wire

Published

- 4 min read

By

LangGraph CVE: SQLi to RCE in AI Agents

LangGraph LangChain CVE-2025-67644 CVE-2026-28277 CVE-2026-27022 RCE SQL injection deserialization AI agents agentic AI vulnerability
img of LangGraph CVE: SQLi to RCE in AI Agents

Three vulnerabilities in LangGraph’s persistence layer. Two of them chain into remote code execution. And LangGraph, if you haven’t been tracking its growth, now has over 50 million monthly downloads as the default way to build stateful, multi-step AI agents.

Check Point Research published the findings on June 15, covering what they describe as an “AI agent memory” security problem: the same checkpoint infrastructure that lets agents remember context across sessions also introduces an attack surface that most developers haven’t considered.

The Vulnerability Chain

LangGraph’s checkpointer is how agents persist state. When an agent completes a step, the checkpointer writes the result to a store, SQLite or Redis being the two most common backends. When the agent resumes or a developer queries history, it reads that state back.

The problem is in how state gets queried.

CVE-2025-67644 (CVSS 7.3) is a SQL injection vulnerability in the SQLite checkpointer’s _metadata_predicate() function, fixed in langgraph-checkpoint-sqlite 3.0.1. If an application exposes get_state_history() with a filter parameter derived from user input, an attacker can inject SQL and read or modify checkpoint data they shouldn’t have access to.

CVE-2026-28277 (CVSS 6.8) is where the chain escalates. The langgraph package before 1.0.10 uses msgpack to deserialize checkpoint data when loading state. An attacker who can write to the checkpoint store via the SQLi above can craft a checkpoint that triggers object reconstruction during deserialization, a classic unsafe deserialization pattern, but in a context most people associate with data storage rather than code execution.

Together: SQLi writes a malicious checkpoint, deserialization executes it when the state is loaded. Full server-side RCE.

CVE-2026-27022 (CVSS 6.5) is a parallel issue in the Redis checkpointer, a RediSearch query injection in @langchain/langgraph-checkpoint-redis before 1.0.2 that allows access control bypass. It doesn’t chain to RCE in the same way, but lets an attacker read checkpoint data across thread namespaces that should be isolated.

Why This Matters More Than a Typical Framework CVE

A vulnerable Python web framework might give an attacker access to the application server. A vulnerable LangGraph deployment gives an attacker access to something more valuable: everything the agent is connected to.

LangGraph agents are commonly wired to external services. LLM API keys, CRM credentials, database connections, internal API tokens. Agents that handle customer support, data analysis, or internal automation accumulate significant access by design. The checkpoint store holds everything they’ve done and what they have access to.

Check Point frames this as “when your AI agent’s memory becomes a security liability.” That’s accurate. The persistence layer that makes agents useful across sessions is also the attack surface.

Who’s Actually at Risk

The attack requires that the application exposes get_state_history() with a user-controlled filter parameter. Not every LangGraph deployment does this. But LangGraph documentation examples and many tutorials include filter-by-metadata patterns that pass user input directly, so plenty of production deployments will be running exactly this.

Self-hosted deployments are the affected class. The SQLite checkpointer is common in local development and smaller deployments; Redis is more typical in production. The managed LangSmith Deployment platform uses PostgreSQL as its checkpoint store and is not affected by any of the three CVEs.

Patching

All three issues have fixes:

  • langgraph-checkpoint-sqlite 3.0.1 or later (addresses CVE-2025-67644)
  • langgraph 1.0.10 or later (addresses CVE-2026-28277)
  • langgraph-checkpoint-redis 1.0.2 or later (addresses CVE-2026-27022)

If you’re running self-hosted LangGraph with SQLite or Redis checkpointers, update now. If patching is blocked by environment constraints, audit whether get_state_history() is exposed to user-controlled input and restrict that at the application layer until you can update.

LangSmith Deployment users: nothing required on your end.

References

Frequently Asked Questions

Which LangGraph deployments are affected?
Self-hosted LangGraph deployments using the SQLite checkpointer (langgraph-checkpoint-sqlite before 3.0.1) or Redis checkpointer (langgraph-checkpoint-redis before 1.0.2) are affected, specifically where the application exposes get_state_history() with user-controlled filter input. LangChain's managed platform, LangSmith Deployment, runs PostgreSQL and is not vulnerable to any of the three CVEs.
What can an attacker access if they exploit this chain?
A successful exploit gives an attacker code execution on the LangGraph server. From there, they can reach everything the agent has access to: LLM API keys stored in environment variables, customer data and conversation histories in the checkpoint store, and credentials for external systems the agent is connected to, such as CRMs, internal APIs, and databases. The agent's trust position in the infrastructure makes this high-value.
How quickly should teams patch?
Immediately. All three CVEs have patches available now. Update to langgraph-checkpoint-sqlite 3.0.1 or later, langgraph 1.0.10 or later, and langgraph-checkpoint-redis 1.0.2 or later. If you cannot patch immediately, audit whether your application exposes get_state_history() to user-controlled input and restrict that path at the application layer as a temporary control.