LangGraph is helping you build complex, stateful, multi-agent AI applications. It's open-source, built by LangChain, and widely used by developers who want more control than managed platforms offer.

But researchers just uncovered a LangGraph critical vulnerability chain that could turn that flexibility into a nightmare.

Three now-patched security flaws including a SQL injection bug and an unsafe deserialization issue can be chained together to achieve remote code execution on self-hosted LangGraph servers.

Here's what happened, what's fixed, and what you need to do right now.

The Three Flaws at a Glance

Check Point security researcher Yarden Porat discovered and reported all three vulnerabilities. They affect different components of LangGraph, but together they form a nasty attack chain.

The LangGraph critical vulnerability chain combines the first two—CVE-2025-67644 and CVE-2026-28277—to achieve full remote code execution on a vulnerable server.
The Redis issue (CVE-2026-27022) is separate but still serious. It can be used to bypass access controls.

Who Is Affected?

The attack chain is exploitable in self-hosted LangGraph deployments that use the SQLite or Redis checkpointer with user-controlled filter input.

If you're running LangGraph on your own infrastructure, pay close attention.
If you're using LangChain's managed platform -LangSmith Deployment- you're safe. The managed service is not affected.

That distinction matters. The LangGraph critical vulnerability chain only applies to self-hosted environments where an attacker can interact directly with the checkpointing system.

How the Attack Works

The attack hinges on one specific endpoint: get_state_history(). This endpoint allows retrieval of historical checkpoints based on metadata filters. In a secure deployment, that's a feature. In a vulnerable one, it's an opening.

Here's the step-by-step chain that leads to remote code execution:

Step 1: Malicious Code Construction

Utilizing msgpack, a payload is created by an attacker to provide instructions for requesting an arbitrary command on the targeted server.

Step 2: SQL Injection

An attacker uses an SQL injection by sending a malformed “filter” parameter that takes advantage of a vulnerability in the SQLite checkpointer. The attacker’s SQL statement causes the database to return a “fake” checkpoint row with the attacker’s serialized data in its checkpoint column.

Step 3: Dangerous Unpacking of Objects

When the application executes a query against a database (in this case, querying for a fake row identified as a checkpoint) this is the process where the application is reconstructing the serialization associated with that checkpoint and indicates that their payload as reconstructed is now active objects due to the unsecure acquisition of the serialized object. 

Step 4: Remote Code Execution (RCE) 

After the payload has been reconstructed, its executed on the server and thus gives the attacker full control of the server.

In other words, the attacker uses the SQL Injection method to trick the database into returning fraudulent/compromised results, and uses unsafe deserialization to convert these results into operating code on the victim's server.

What LangGraph Says About the Risk

LangGraph's maintainers acknowledge the issue but frame it as a post-exploitation concern.

In their assessment, successful exploitation of the LangGraph critical vulnerability chain requires the attacker to already have write access to the checkpoint store. In typical hosted configurations (like LangSmith), that access is prevented.

However, they add that an attacker who gains write access to the checkpoint store could escalate that access to code execution. That escalation could expose runtime secrets or provide access to other systems the runtime can reach.

So the real risk is for self-hosted deployments where checkpoint storage is not properly isolated.

Why This Matters for AI Security

Check Point's research highlights something important. Classic vulnerabilities like SQL injection become more dangerous when they show up inside AI agent frameworks.

Why? Because AI agents can be trusted with higher levels of access than other apps and can access and run commands from other people, so compromising the agent framework is like compromising a very powerful insider.

The LangGraph critical vulnerability incident serves as a reminder that "AI Security" is not just about prompt injection or model poisoning, its also about the boring stuff like input validation, deserialization security, and access control.

Redis Vulnerability (CVE-2026-27022)

On a related note, CVE-2026-27022 affects the @langchain/langgraph-checkpoint-redis library, specifically the Redis checkpointer prior to 1.0.1.

CVE-2026-27022 is a query injection issue for RediSearch which could allow an attacker to bypass access control and therefore potentially read or modify checkpoint data to which they should not have access.

Although this vulnerability is not as severe as the RCE exposure chain, it does present a risk to any users of Redis who are using it for their checkpointing system.

Patches Are Available

There were patches for all three vulnerabilities that were patched above. After installing all three patches, the following is required to update your systems for the LangGraph project:
1. Update langgraph-checkpoint-sqlite version to 3.0.1 or higher
2. Update langgraph (the core library) to 1.0.10 or higher
3. Update @langchain/langgraph-checkpoint-redis to 1.0.1 or higher

If you're using self-hosted LangGraph, you should implement all of the above updates immediately.

Securing Your LangGraph Deployment

In addition to patching your LangGraph Deployment, Check Point recommends several other hardening measures for any organization that hosts a LangGraph instance on their own infrastructure:

1. Add authentication to self-hosted LangGraph servers and do not allow access to the get_state_history() endpoint without additional access control.
2. Use short-term static secrets. Rotate your credentials often.
3. Use network segmentation by placing the LangGraph Server within a separate network segment and preventing it from communicating directly with sensitive internal systems.
4. AI Agents need to be viewed similarly to high value identity and held accountable according to the same level of privilege as other accounts with high levels of privilege.
5. Use the least privileged access model (PoLP) as the basis for granting access to an agent (e.g. do not grant access to the file system, if the agent only needs access to a specific database). 
6. Validate all user-supplied filter inputs. The SQL injection in this chain came from unsanitized metadata filter keys. Treat those inputs like any other untrusted data.

The Bottom Line

The LangGraph critical vulnerability chain is a clear warning for anyone building AI applications on self-hosted infrastructure. SQL injection and unsafe deserialization are decades-old problems. But inside an AI framework with elevated privileges, they become RCE vectors.

LangSmith users can breathe easy. The managed platform is not affected.
Everyone else: patch now, lock down your checkpointer access, and treat your AI agents like the privileged insiders they are.

FAQ Section

What is the LangGraph critical vulnerability chain?

It's a combination of CVE-2025-67644 (SQL injection in SQLite checkpointer) and CVE-2026-28277 (unsafe msgpack deserialization) that can lead to remote code execution on self-hosted LangGraph servers.

What vulnerabilities exist for the various versions of LangGraph?

Any version prior to 1.0.10, langgraph-checkpoint-sqlite prior to 3.0.1 and @langchain/langgraph-checkpoint-redis prior to version 1.0.1 have security vulnerabilities.

Will LangSmith be impacted by these vulnerabilities?

There will not be any impact caused to Langsmith from these vulnerabilities. The Langsmith deployment managed by LangChain will also not be impacted by these vulnerabilities. Only self-hosted deployments of LangGraph run the risk of potential impact from this security issue.

How can an attacker exploit this chain?

An attacker exploits SQL injection to inject malicious checkpoint data, then triggers unsafe deserialization when that checkpoint is loaded. The result is remote code execution on the server.

Have patches been released?

Yes. Update 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.

How do I protect my self-hosted LangGraph deployment?

Apply the patches immediately. Then implement authentication, network segmentation, least privilege access, and validate all user-supplied filter inputs.

Source: The Hacker News