LangGraph checkpoint flaws chain SQL injection into remote code execution

On 12 June 2026, The Hacker News reported Check Point research on three now-patched flaws in LangGraph, the agent orchestration library from LangChain. Two of them, CVE-2025-67644 and CVE-2026-28277, can be chained: a SQL injection plants a fake checkpoint row, and unsafe deserialization runs the code inside it. The researcher, Yarden Porat, found all three.

LangChain's managed LangSmith Deployment is not affected. The risk is to self-hosted deployments that use the SQLite or Redis checkpointer and pass user-controlled input into filters.

What's affected

The reported chain works like this:

1. The application exposes an endpoint that calls get_state_history(), which returns checkpoints filtered by metadata.
2. The attacker crafts a msgpack payload that contains code to run.
3. A malicious filter key uses the SQL injection to add a fake checkpoint row to the results, with the payload in its checkpoint column.
4. The application deserializes that checkpoint blob.
5. The deserialization runs the payload on the server.

LangGraph classifies CVE-2026-28277 as post-exploitation, since on its own it needs write access to the checkpoint store. The SQL injection is what supplies that write path. The Redis issue is separate from the chain. The individual advisories are older than the research write-up: the SQLite one was published on 9 December 2025 and the msgpack one on 5 March 2026.

How to check if you're exposed

pip list 2>/dev/null | grep -iE "langgraph|langchain"
npm ls @langchain/langgraph-checkpoint-redis 2>/dev/null

Then search your code for the exposure pattern: user-controlled values reaching checkpoint filters.

grep -rnE "get_state_history|alist\(|filter=" --include=*.py . | head -40

If any request parameter flows into a filter dictionary, treat the endpoint as exposed until you upgrade. Safeguard's reachability analysis answers the same question automatically, by checking whether your code actually calls the vulnerable function.

What to do now

1. Upgrade langgraph-checkpoint-sqlite to 3.0.1 or later, langgraph to 1.0.10 or later, and @langchain/langgraph-checkpoint-redis to 1.0.1 or later.
2. For the msgpack issue, the advisory recommends hardening with the LANGGRAPH_STRICT_MSGPACK environment variable or the allowed_msgpack_modules setting, which restrict which types can be rebuilt on load.
3. Never pass raw user input as filter keys. Allow a fixed set of keys and reject the rest.
4. Add authentication to any self-hosted LangGraph server.
5. Segment the network so the checkpoint store is not reachable from places the application does not need.
6. Replace long-lived static secrets in agent environments with short-lived credentials.

How this could have been avoided

• Validate filter keys against an allowlist. The SQL injection came from metadata filter keys. Accepting only known keys would have stopped the entry point.
• Do not deserialize data that a user could have influenced. The checkpoint blob was trusted because it came from the database. Treat persisted state as untrusted when any request can write to it.
• Restrict who can write the checkpoint store. The second flaw needed write access. Separate credentials for the application and for any query-facing path limit the damage.
• Authenticate the agent server. The chain is reachable only when an outsider can call the history endpoint.

Why it matters

Agent frameworks keep state, and state is a new place where untrusted data lives. A conversation history looks like a log, but when the framework reloads it into objects, it is an input format.

Neither flaw looks like a remote code execution bug alone. The SQL injection scores 7.3 and the deserialization issue 6.8, and the advisory for the latter calls it a post-exploitation, defense-in-depth issue. Together they reach code execution. Triage by score would leave both in the middle of the queue, which is why chains matter more than individual numbers.

Try it yourself

Pick one agent service you run. List every place it reads state back: a database, a cache, a file. For each, ask who can write there and whether the framework rebuilds objects from it. Then explore how reachability analysis narrows a vulnerability list to the calls your code really makes.

Click through it at your own pace, or open it full screen.

Quick check

Sources

• GitHub Advisory Database: GHSA-9rwj-6rc7-p77c (CVE-2025-67644)
• GitHub Advisory Database: GHSA-g48c-2wqr-h844 (CVE-2026-28277)
• The Hacker News: LangGraph flaw chain exposes self-hosted AI agents to remote code execution