Critical LangGraph Vulnerability Chain Could Let Attackers Take Over Self-Hosted AI Agent Servers

A critical vulnerability chain in LangGraph could let attackers move from query injection to remote code execution on vulnerable self-hosted AI agent servers.

Check Point Research says the issue affects LangGraph’s checkpointer layer, which stores and retrieves the execution state of AI agents. The riskiest attack path combines a SQLite injection flaw with unsafe msgpack deserialization.

The exposure is not universal. The main risk applies to self-hosted LangGraph deployments that use SQLite or Redis checkpointers and expose get_state_history() with user-controlled filter input.

LangGraph Checkpointers Turned Into an Attack Path

LangGraph is an open-source framework for building stateful and long-running AI agents. The LangGraph GitHub repository describes it as a low-level orchestration framework for building, managing, and deploying stateful agents.

Checkpointers are central to that model. They save agent state so a workflow can resume later, recover from failure, or continue across multiple steps.

That design also creates a sensitive trust boundary. If an attacker can manipulate checkpoint queries or stored checkpoint data, they may influence what the agent runtime loads next.

Issue	Affected component	Impact	Fixed version
CVE-2025-67644	langgraph-checkpoint-sqlite	SQL injection through SQLite checkpoint metadata filter keys	3.0.1 or later
CVE-2026-28277	langgraph	Unsafe msgpack deserialization that can lead to code execution	1.0.10 or later
CVE-2026-27022	@langchain/langgraph-checkpoint-redis	RediSearch query injection in Redis checkpoint filtering	1.0.2 or later

How the LangGraph RCE Chain Works

The most serious chain starts with the SQLite checkpointer. The CVE-2025-67644 advisory says LangGraph SQLite Checkpoint versions 3.0.0 and earlier allowed SQL injection through checkpoint metadata filter keys.

That SQL injection can let an attacker manipulate checkpoint database queries if the application accepts untrusted filter keys in checkpoint search operations.

The second link is unsafe msgpack deserialization. The CVE-2026-28277 advisory says LangGraph versions 1.0.9 and earlier could load msgpack-encoded checkpoints that reconstruct Python objects during deserialization.

• An application exposes state history lookup with user-controlled filters.
• An attacker abuses the SQLite filter flaw to manipulate checkpoint query results.
• The attacker causes a crafted checkpoint payload to be loaded.
• The unsafe deserialization path can trigger code execution in the LangGraph runtime.

Redis Deployments Had a Separate Injection Risk

The Redis issue is tracked as CVE-2026-27022. The Redis advisory says @langchain/langgraph-checkpoint-redis constructed RediSearch queries by interpolating user-provided filter keys and values without proper escaping.

This could let attackers manipulate query logic and bypass access controls in Redis-backed checkpoint deployments. It does not independently create the same RCE path by itself, but it affects the same sensitive checkpoint layer.

Check Point said the Redis issue introduces a parallel injection class in deployments using the Redis checkpointer. Organizations that use Redis-backed LangGraph state should patch even if they do not use SQLite.

Deployment type	Risk level	Reason
Self-hosted LangGraph with SQLite checkpointer and user-controlled filters	High	Can enable the SQL injection to unsafe deserialization chain
Self-hosted LangGraph with Redis checkpointer and user-controlled filters	High	Can expose checkpoint data through RediSearch query injection
Self-hosted LangGraph without exposed state-history filters	Lower	The reported chain requires a reachable filter input path
LangSmith managed deployments	Not affected by this primary chain	Check Point says LangSmith Deployment uses PostgreSQL and was not vulnerable to the reported SQLite or Redis path

Why AI Agent Servers Are High-Value Targets

The impact can be severe because AI agent servers often hold more than prompts and chat history. They can also hold API keys, tool credentials, customer data, workflow state, and access to internal services.

The LangGraph project supports long-running workflows, persistent memory, human-in-the-loop review, and agent state management. Those features make the framework useful for production automation, but they also increase the value of the runtime environment.

If attackers gain code execution on a self-hosted LangGraph server, they may be able to read environment variables, steal LLM API keys, access connected tools, inspect stored conversations, or pivot into internal systems that the agent can reach.

Patched Versions Are Available

LangChain has patched the reported issues. Organizations should update langgraph-checkpoint-sqlite to 3.0.1 or later, langgraph to 1.0.10 or later, and @langchain/langgraph-checkpoint-redis to 1.0.2 or later.

The SQLite advisory confirms that the SQL injection issue is fixed in version 3.0.1.

The msgpack advisory says version 1.0.10 adds an allowlist-based hardening mechanism for checkpoint deserialization and recommends enabling strict msgpack behavior where feasible.

Package	Safe version	Recommended action
langgraph-checkpoint-sqlite	3.0.1+	Update immediately if SQLite checkpointers are used
langgraph	1.0.10+	Update and review msgpack deserialization settings
@langchain/langgraph-checkpoint-redis	1.0.2+	Update Redis checkpointer deployments

Teams Should Review More Than Package Versions

Patching is the first step, but it should not be the only response. Teams should also review how their LangGraph applications expose state history and checkpoint search functions.

Applications should not pass raw user-controlled filters directly into checkpoint queries. Developers should validate allowed filter keys, restrict access to state-history APIs, and treat checkpoint stores as integrity-sensitive infrastructure.

The Redis security advisory also shows why filter values and filter keys both need careful escaping and validation in agent persistence layers.

• Update all affected LangGraph packages to patched versions.
• Restrict access to get_state_history() and similar state-inspection endpoints.
• Do not allow users to control raw checkpoint filter keys.
• Limit write access to checkpoint databases and Redis stores.
• Rotate checkpoint-store credentials if exposure is suspected.
• Review agent runtime secrets, including LLM API keys and tool credentials.
• Segment AI agent servers from sensitive internal systems where possible.

LangSmith Managed Deployments Were Not Affected

Check Point said LangSmith Deployment, formerly LangGraph Platform, was not affected by the primary vulnerable path because it uses PostgreSQL rather than the vulnerable SQLite or Redis setups.

That distinction matters. The risk centers on self-hosted deployments using the affected checkpointers with application-level exposure of user-controlled filters.

The same Check Point report still makes a broader point for AI infrastructure. Traditional bugs such as SQL injection and unsafe deserialization can become more damaging when they sit inside systems that store agent memory, credentials, and workflow state.

Security control	Why it helps
Patch vulnerable packages	Removes the known injection and deserialization flaws
Validate checkpoint filters	Prevents users from manipulating query structure
Enable strict msgpack handling	Reduces the risk of unsafe object reconstruction
Limit checkpoint-store access	Protects the integrity of persisted agent state
Reduce agent runtime privileges	Limits the damage if code execution occurs

The LangGraph vulnerability chain shows that AI agent security cannot focus only on prompts. Agent frameworks also need the same hardening expected from any production server, including input validation, safe deserialization, access control, secret isolation, and fast dependency patching.

FAQ