Agent Checkpoint Poisoning: Insecure Deserialization and Rollback Attacks on Agent State Stores

Agent checkpoint poisoning is SSA descriptive wording for a security-relevant write to the serialized snapshot an agent framework saves so a session can pause and resume: a checkpoint row, a session-state cache entry, or a rollback record. The defining mechanism differs from most other entries on this site in one important way. Where plan poisoning and memory injection change what an agent believes or intends to do next, a poisoned checkpoint can change what code the host process itself executes, the instant a later session deserializes it, before the model has generated a single token.

What it is

The defining object is the persisted, serialized representation of an agent's execution state: conversation history, tool-call results, and internal variables, written to a store, usually a database, cache, or file, specifically so a session can be paused, resumed, replayed, or rolled back to an earlier point. This is distinct from a durable memory record, which an agent writes deliberately through a memory tool to persist a fact, and from a plan object, which an agent rewrites through ordinary step-tracking. A checkpoint is infrastructure-level: it is written and read by the framework's own persistence layer, often without the model being aware the write happened at all.

The defining cause splits into two related but separate failure modes. The first is a software weakness in how the checkpoint is deserialized: if the loader accepts arbitrary serialized objects, such as Python pickle data, and reconstructs them without restriction, an attacker who can get controlled bytes into the store gets code execution on whatever process loads that checkpoint next. The second is a design gap independent of any parsing bug: even a checkpoint that deserializes safely can restore a state whose assumptions, external effects, and security invariants never coexisted in any single valid execution, because rollback re-enters a world where dependencies the original run relied on, a file, a price, a permission, have since changed.

What it is not

A sandbox-escape technique that breaks execution isolation directly, with no persistence layer involved.
Sandbox configuration escape, where an already-compromised session writes to host-trusted configuration or hooks that a later launch reads. That entry path targets files the sandbox's own design treats as legitimate startup input; this one targets a data store the framework deserializes as executable state.
Agent plan poisoning, where injected content changes the semantic content of a task list the agent itself reasons over. A poisoned checkpoint can carry a poisoned plan as one field inside it, but the checkpoint attack succeeds at the deserialization layer, before any reasoning over the content occurs.
Persistent memory injection, where a deliberate memory-write tool call inserts a false fact or instruction. A checkpoint write is usually made by the framework's own persistence code, not by a tool the model chose to call.
Reproducible exploit code, working payloads, or step-by-step instructions for compromising a specific product's checkpoint format.

In scope

Checkpoint, session-cache, or rollback stores that accept attacker-influenced content, directly or through a chained vulnerability such as SQL injection into a filter parameter.
Deserialization logic that reconstructs arbitrary objects, especially a pickle fallback, from checkpoint data without restricting what types or calls it permits.
Shared checkpoint stores, such as a Redis or Postgres backend, where one user's session can write a record a different user's session later loads.
Rollback or resume operations that restore a prior state without re-validating that the assumptions and external effects behind that state still hold.
Defensive controls for restricted deserialization, provenance checking, and safe rollback design.

Target state and trust boundaries

The target state is the checkpoint store and, transitively, whatever process loads it. The trust boundary that fails is the assumption that a record already present in the checkpoint store was put there by the framework's own legitimate execution, rather than by anyone with write access to the store, whether through direct access, an injection vulnerability in a query path, or a prompt-injected instruction that reaches the checkpoint indirectly. A second, subtler trust boundary sits at the rollback operation itself: restoring a checkpoint assumes the state it captures is still a valid, self-consistent point to resume from, an assumption that does not automatically hold once external systems have moved on since the checkpoint was written.

Persistence

A checkpoint store is, by design, shared-system persistence: multiple sessions, and in several documented cases multiple distinct users, read from and write to the same underlying database or cache. A poisoned record does not need the same session, or even the same user, to trigger it. It waits until any session loads that specific checkpoint, which can be hours or days after the write, and can be triggered by someone with no involvement in planting it.

What the research establishes

Check Point Research disclosed a chain of vulnerabilities in LangGraph's checkpointer, one of the most widely used agent-persistence layers, on 2026-06-11. A SQL injection in the SQLite checkpointer's filter-query path (CVE-2025-67644) let an attacker inject a fabricated checkpoint row through a crafted UNION SELECT; a separate unsafe msgpack deserialization flaw (CVE-2026-28277) then executed arbitrary code when that fabricated row was loaded, via a handler that called getattr(importlib.import_module(...), ...) on attacker-controlled module and function names. A parallel SQL injection affected the Redis checkpointer (CVE-2026-27022). The chain was fixed in langgraph-checkpoint-sqlite 3.0.1, langgraph 1.0.10, and langgraph-checkpoint-redis 1.0.2 (Check Point Research, From SQLi to RCE: Exploiting LangGraph's Checkpointer). A related, independently tracked issue, CVE-2026-27794, affected LangGraph's separate caching layer: any application that enabled a BaseCache backend with CachePolicy on a node inherited a default of JsonPlusSerializer(pickle_fallback=True), so an attacker with write access to the cache could get pickle-based code execution; the fix in LangGraph Checkpoint 4.0.0 disabled the pickle fallback by default (CVSS 6.6, SentinelOne Vulnerability Database, CVE-2026-27794).

The cross-session risk is not theoretical. At Black Hat on 2026-08-05, Check Point researchers Yarden Porat and Shahar Tal disclosed a checkpoint deserialization flaw in Microsoft Agent Framework in which the attack and the trigger belonged to two different people: one user's session plants a payload through prompt injection into a checkpoint; a separate user later rewinds their own, unrelated session, and loading that checkpoint fires the payload with shell access on the server. As Tal put it, "one person's message plants the payload, and then a different person rewinds their own session, which triggers the payload, and now the attacker has a shell on that server." Microsoft paid a $10,000 bounty and shipped mitigations, including a restricted unpickler for FileCheckpointStorage and CosmosCheckpointStorage that permits only a fixed set of safe Python and SDK types; because the framework was not yet generally available when the researchers reported it, Microsoft did not assign a CVE (The Register, Prompt injection isn't the bug, AI agent frameworks are, 2026-08-05).

Academic work extends the concern beyond deserialization bugs to rollback correctness itself. Wu et al.'s *Safe to Resume? Breaking Execution Continuity of Agent Execution via Rollback* argues that "correct rollback does not imply secure recovery: a faithfully restored checkpoint may resume an execution whose states, assumptions, and external effects never coexisted in any valid history," and catalogs five failure modes, including incomplete state restoration, stale external dependencies, and unrecorded external effects. The paper demonstrates end-to-end attacks exploiting this gap against three systems: a malware-verification bypass in Hermes, unauthorized mail forwarding in Cline, and a double-payment condition in LangGraph (arXiv 2608.29381, Wu, Li, Jiang, Niu, Wang, and Zhang). None of these cases required a deserialization bug at all; the state was restored exactly as saved, and that fidelity was itself the problem.

Detection: observable signs

A checkpoint or session-cache write originates from a query path, filter parameter, or field that accepts user-influenced input with no parameterization or type restriction.
A deserialization call in the checkpoint-loading path can reconstruct arbitrary object types rather than a fixed, allow-listed set.
A checkpoint store is reachable by more than one user or session, with no per-owner access check enforced at read time.
A rollback or resume operation re-executes external side effects, such as a payment, a send, or a permission grant, with no check for whether that effect already occurred before the checkpoint was written.
Unusually large or malformed serialized payloads appear in checkpoint records compared to a session's typical state size.

Useful telemetry includes an allow-list violation log for every deserialization call in the checkpoint path, write-provenance tagging on every checkpoint record showing which session and user produced it, and a record of which external side effects a rollback operation re-triggered versus skipped.

Defenses, containment, and recovery

The table below is SSA editorial guidance for defenders. It is neither a standard requirement nor a measured effectiveness ranking.

Control	Transition it interrupts	Applicability	Residual risk and verification
Restricted, allow-listed deserialization (no pickle fallback by default)	Attacker-controlled serialized data executing code on load	Any agent framework with a checkpoint, cache, or session-resume store	Vendor patches such as LangGraph 4.0.0's default-off pickle fallback close the specific path tested; verify no code path still opts back into unrestricted deserialization.
Parameterized queries on every checkpoint filter or lookup path	SQL injection used to plant a fabricated checkpoint row	Checkpoint stores backed by SQL or SQL-like query interfaces	Closes the injection vector, not the deserialization vector behind it; both must be fixed, since either alone reproduces a documented CVE chain.
Per-owner access scoping on shared checkpoint stores	A payload planted in one user's session firing when a different user's session loads it	Multi-tenant or multi-user deployments sharing a Redis, Postgres, or similar backend	Scoping prevents cross-user triggering but not a single user's own session being turned against them; pair with input sanitization upstream of the write.
Side-effect re-validation before rollback replay	A restored checkpoint re-executing an external effect, such as a payment or send, that already happened	Any agent with rollback or resume capability touching external systems	Requires the framework to track which side effects a checkpoint's saved state already caused, which most current checkpoint formats do not record by default.
Provenance and integrity tagging on checkpoint writes	An unauthenticated or injected write being treated the same as a framework-originated one	Any checkpoint store reachable by more than trusted framework code	Tagging only helps if the loader actually checks it before deserializing; verify enforcement, not just presence of the tag.

Prevention should treat every checkpoint-loading path as an untrusted-input boundary, the same posture applied to network input, not as a trusted internal handoff. Detection should watch for deserialization calls reconstructing unexpected types and for checkpoint writes originating outside the framework's own execution path. Containment should halt further checkpoint loads from a suspect store and isolate the process that deserialized a poisoned record, since code execution during deserialization can already have run before any output reaches the user. Recovery should rebuild from a checkpoint confirmed to predate the compromise, and re-validate any external side effect the affected session may have triggered rather than assuming the restored state accurately reflects what actually happened in the world.

Boundaries with similar concepts

Agent checkpoint poisoning sits at the intersection of what OWASP's Agentic Top 10 separates into two categories. ASI05:2026 Unexpected Code Execution covers the deserialization-bug half of this article, where malformed or malicious data reaching an interpreter or unpickler produces arbitrary code execution. ASI06:2026 Memory & Context Poisoning covers the state-integrity half, where a restored checkpoint carries content an agent later treats as trusted operative state. A single incident, such as the LangGraph SQLi-to-RCE chain, can trigger both categories in sequence: the injection plants poisoned state, and the deserialization bug executes it.

This differs from sandbox configuration escape in what fails and when. That entry path targets host-trusted configuration files and hooks a sandboxed session writes for a later, less-restricted launch to read as legitimate startup input. This entry path targets a data store the framework's own persistence code deserializes as executable state, and the failure can occur at load time regardless of whether any sandbox boundary was ever crossed.

Mapping to standards and research

Source	Source-owned term or item	Relationship to this article
Check Point Research (2026-06-11)	LangGraph checkpointer SQLi-to-RCE chain; CVE-2025-67644, CVE-2026-28277, CVE-2026-27022	Direct, CVE-documented evidence of a checkpoint deserialization RCE chain in a widely used agent-persistence layer.
SentinelOne Vulnerability Database	CVE-2026-27794	Independently tracked LangGraph caching-layer pickle-fallback deserialization vulnerability and its fix.
Check Point Research; The Register (2026-08-05)	Microsoft Agent Framework checkpoint deserialization RCE	Documented, cross-session, cross-user exploitation of a checkpoint deserialization flaw via prompt injection and rollback.
arXiv 2608.29381	"Safe to Resume?" rollback-security framework and five failure modes	Academic evidence that checkpoint restoration can violate security invariants without any deserialization bug present.
OWASP Top 10 for Agentic Applications 2026	`ASI05:2026 Unexpected Code Execution`; `ASI06:2026 Memory & Context Poisoning`	The two broader risk categories this pattern spans, depending on whether the failure is a parsing bug or a state-trust gap.
MITRE, CWE	`CWE-502 Deserialization of Untrusted Data`	The general software-weakness classification underlying the deserialization half of this pattern.
Agent State Attack	Agent checkpoint poisoning	SSA descriptive phrase, not attributed to the sources above.

Related terms

Agent state attack: the umbrella definition, including tool and environment state among the listed target states.
Sandbox configuration escape: the adjacent surface targeting host-trusted configuration and hooks rather than a deserialized checkpoint store.
Agent plan poisoning: the adjacent surface targeting the semantic content of a live task list rather than the serialization layer beneath it.
Persistent memory injection: the adjacent surface targeting an explicit memory-write tool call rather than the framework's own checkpoint persistence code.

FAQ

Does this only affect agents built on LangGraph?

No. LangGraph is the source of the most detailed public disclosures to date, but the Microsoft Agent Framework case shows the same class of flaw in a different, independently developed persistence layer. Any framework that serializes execution state to a shared store and deserializes it on resume is a candidate, regardless of vendor.

Is this the same risk as a general sandbox escape?

No. A sandbox escape breaks execution isolation directly, typically through a kernel or container flaw. This pattern can grant code execution with no sandbox boundary crossed at all, because the vulnerable step is deserializing a data store the host process already trusts, not breaking out of a restricted environment.

If a framework doesn't use pickle, is it safe?

Not automatically. The LangGraph SQLi-to-RCE chain used msgpack, not pickle, for the code-execution step; pickle fallback was the separate CVE-2026-27794 issue. Any deserialization format that can reconstruct arbitrary types or invoke arbitrary functions carries similar risk, regardless of which serialization library is in use.

Does fixing the deserialization bug eliminate the risk?

It eliminates the code-execution path specifically. The rollback-correctness problem documented in arXiv 2608.29381 is separate and survives a fully safe deserializer: a checkpoint can restore a state that deserializes correctly but no longer reflects a valid, self-consistent point in the world, because external systems moved on after the checkpoint was written.

Sources

Verification and change history

Standards and versions referenced: OWASP Top 10 for Agentic Applications, Version 2026 (December 2025); CWE-502; CVE-2025-67644, CVE-2026-28277, CVE-2026-27022, CVE-2026-27794; arXiv 2608.29381.

Last verified: 2026-09-18. The Check Point Research disclosure details, the SentinelOne CVE record, The Register's Black Hat coverage, and the arXiv abstract were read from the sources' own pages on this date. The OWASP category identifiers and CWE-502 were reused from public, current listings.

Change history: 2026-09-18, first version.

Working-term label: Mixed provenance. CVE-2025-67644, CVE-2026-28277, CVE-2026-27022, and CVE-2026-27794 are Standard-identified vulnerabilities. CWE-502 is a Standard Term owned by MITRE. ASI05:2026 and ASI06:2026 are Standard Terms owned by OWASP. "Agent checkpoint poisoning" is SSA descriptive wording, not a standard or industry term.