An agent's saved state is part of its security boundary. On June 11, Check Point Research showed a chain in which an exposed LangGraph history filter could alter a checkpoint query, insert a forged checkpoint result and trigger code execution when that result was loaded. This was a researcher-demonstrated exploit chain, not a reported breach of every LangGraph deployment.
A checkpointer saves an agent's execution state so a workflow can resume or inspect earlier steps. In the affected SQLite implementation, a metadata filter key could be inserted into a database query without adequate validation. A second flaw allowed specially crafted checkpoint data to reconstruct unsafe Python objects when loaded. Check Point combined the paths in its demonstration to reach code execution in the agent application's runtime.
Who needed to be concerned?
The important condition is exposure. The demonstrated chain concerned custom, self-hosted applications using the affected checkpointer and passing an untrusted filter into checkpoint history, for example through `get_state_history()`. The LangGraph maintainer's advisory says LangSmith Deployment customers were not affected by the SQLite filter flaw because that vulnerable path was unavailable there. The separate unsafe-deserialization advisory describes a post-exploitation risk when an attacker can control checkpoint bytes.
The relevant fixes were available before Check Point published its June analysis: `langgraph-checkpoint-sqlite` 3.0.1 addresses the filter injection, and `langgraph` 1.0.10 addresses unsafe msgpack checkpoint loading. Check the actual packages and versions in each deployment. A version number alone does not tell you whether your application exposed the vulnerable path, and the public research does not establish widespread exploitation.
What should a review cover?
- Step 01Identify where each agent stores checkpoints and which services or users can read, write or query them.
- Step 02Find any history endpoint that accepts filter keys from users or other untrusted sources. Validate the input and apply the maintainer's patched versions.
- Step 03Test whether checkpoint-store access could reach another user's state or the agent host. Keep database permissions and runtime privileges narrow, and retain logs that support investigation.
HikmaAI can help assess supported agent interactions, apply controls on protected paths and retain evidence of those decisions. A framework's internal checkpoint read may never cross that protected path. Its package patch, application input validation and storage permissions must be checked directly.
The lesson for buyers is concrete: review the state store as carefully as the agent's tools. Memory and history are useful features, but they also create inputs and permissions an attacker may try to reach.
