LangGraph Flaw Chain Exposes Self-Hosted AI Agents to Remote Code Execution

Three security flaws in LangGraph, the open-source framework LangChain built for stateful, multi-agent AI applications, have been patched after researchers showed that two of them could be chained into full remote code execution. The disclosure, credited to security researcher Yarden Porat and published by Check Point, lands on a familiar problem in an unfamiliar place: classic web vulnerability classes showing up inside AI agent infrastructure that carries far more privilege than a typical web app component.

The headline issue is a SQL injection that, on its own, would rate as a serious but contained bug. Combined with an unsafe deserialization flaw, it becomes a path to running arbitrary code on the server hosting an AI agent. That distinction matters, and it is the part worth understanding rather than the CVE numbers alone.

What was found

The three vulnerabilities affect different checkpoint backends that LangGraph uses to persist agent state:

• CVE-2025-67644 (CVSS 7.3): A SQL injection in LangGraph's SQLite checkpoint implementation. Attackers can manipulate SQL queries through metadata filter keys. Fixed in langgraph-checkpoint-sqlite 3.0.1.
• CVE-2026-28277 (CVSS 6.8): An unsafe msgpack deserialization flaw that triggers object reconstruction when a tampered checkpoint is loaded. Fixed in langgraph 1.0.10.
• CVE-2026-27022 (CVSS 6.5): A RediSearch query injection in @langchain/langgraph-checkpoint-redis that can bypass access controls. Fixed in version 1.0.1.

Check Point was direct about scope: "The vulnerability chain is exploitable in self-hosted deployments using the SQLite or Redis checkpointer with user-controlled filter input." LangChain's managed platform, LangSmith Deployment, is not affected. If you run LangGraph yourself with a checkpointer that accepts user-supplied filter input, this is your problem to patch. If you rely on the hosted offering, the threat model does not reach you.

How the chain works

Checkpoints are how LangGraph remembers where an agent is in a long-running, multi-step task. State gets serialized and written to a store, then read back later. The attack abuses the read path.

The chain depends on the application exposing the get_state_history() endpoint, which lets a caller retrieve historical checkpoints by their metadata. From there the steps are:

1. The attacker prepares a msgpack payload containing instructions to execute arbitrary code.
2. They send a malicious filter parameter that exploits the SQL injection (CVE-2025-67644) to return a fake checkpoint row, where the checkpoint column holds attacker-controlled serialized data.
3. When the application processes the query results, it deserializes that BLOB.
4. The unsafe deserialization flaw (CVE-2026-28277) reconstructs the malicious object and runs the payload, handing the attacker code execution on the server.

The injection alone would just leak or manipulate query results. The deserialization flaw alone would require an attacker to already control checkpoint data. Stitched together, the first bug supplies the malicious data that the second bug executes. That is the pattern defenders should internalize: medium-severity issues that look survivable in isolation can combine into something that is not.

The vendor's framing, and why it still matters

LangGraph's maintainers described CVE-2026-28277 as a post-exploitation issue. In their view, successful abuse already requires the ability to write attacker-controlled checkpoint data, and "typical hosted configurations are designed to prevent such access." They noted that escalation from write access to the checkpoint store can "expose runtime secrets or provide access to other systems the runtime can reach."

That framing is technically fair and operationally incomplete. The SQL injection is exactly the mechanism that grants the write-equivalent control the deserialization flaw needs. For self-hosted operators who expose state-history functionality with user-controlled filters, the two findings are not independent risks to weigh separately. They are one attack with two moving parts.

Check Point's broader point is the one to carry forward. SQL injection is a vulnerability class the industry has known how to prevent for two decades. When it surfaces inside an AI agent framework, the blast radius changes. These agents frequently hold API keys, database credentials, and network reach into internal systems, because that access is what makes them useful. Compromising the runtime can mean compromising everything the agent was trusted to touch.

Practical takeaways

For teams running LangGraph in their own infrastructure, the remediation list is straightforward and most of it is good hygiene regardless of these specific CVEs:

• Patch first. Move to langgraph 1.0.10 or later, langgraph-checkpoint-sqlite 3.0.1 or later, and @langchain/langgraph-checkpoint-redis 1.0.1 or later.
• Authenticate self-hosted servers. An exposed agent endpoint without authentication is a much larger problem than any single deserialization bug.
• Avoid long-lived static secrets. Short-lived, scoped credentials limit what an attacker gains from runtime access.
• Segment the network. If the agent runtime cannot reach your crown-jewel systems, code execution there is contained.
• Treat AI agents as privileged identities. Apply least privilege deliberately. An agent should hold the minimum access its task requires, not whatever was convenient during development.

The last point is the durable lesson. As agentic frameworks move into production, they inherit the security expectations of any service that processes untrusted input and holds sensitive credentials. The novelty of the AI layer does not exempt the plumbing underneath from the rules that have always applied to it. Validating filter inputs, refusing to deserialize untrusted data into live objects, and scoping credentials tightly are not new disciplines. They are the same ones, applied to a component that now sits closer to the keys than most web tiers ever did.

The fixes are out, the affected configurations are well defined, and the upgrade path is clean. The work for most teams is confirming which checkpointer they run, whether they expose history endpoints to user-controlled filters, and how much that runtime can reach if someone gets in.