The checkpoint store that let anyone rewrite an agent's memory

> ../failures/checkpoint_store_nosql_injection.md

This is a Failure Report on a real, public disclosure, not an internal incident. In 2026, two CVEs landed against the MongoDB checkpoint and store libraries used by many LangGraph-based agents: CVE-2026-48121 (NoSQL parameter injection in MongoDBSaver.getTuple, via thread_id/checkpoint_ns/checkpoint_id from config.configurable) and CVE-2026-55253 (operator injection in MongoDBSaver.list and MongoDBStore.search filter dictionaries). Both allow cross-tenant access to saved agent state. The failure mode is easy to miss even if you are careful about the parts of your stack you already worry about.

§ 01 · What the checkpoint store actually does

LangGraph and similar frameworks persist an agent's state, conversation history, intermediate reasoning, tool outputs, the decisions it has made so far in a multi-step run, to a database, so a long-running or resumable agent does not lose its place if a process restarts. Most teams treat this store the way they would treat a session cache: important for continuity, not typically thought of as an attack surface.

── The vulnerability ──

§ 02 · What the vulnerability actually allows

The disclosed flaw is a NoSQL injection in how certain checkpoint fields get queried. Because MongoDB query-operator keys (those prefixed with $, such as $gt, $ne, $regex, or $where) are not rejected during query construction, an attacker who can influence input that eventually flows into a checkpoint query, which, in an agent system, can be surprisingly indirect, since agent state is often built from tool outputs and user messages, can manipulate the query itself. That means reading or altering another tenant's saved state, not just the run they are nominally interacting with.

── Worse for agents ──

§ 03 · Why this is worse than it sounds for agents specifically

A NoSQL injection against a normal application typically exposes or corrupts data. A NoSQL injection against an agent's checkpoint store can rewrite what the agent believes has already happened. An agent that resumes from a tampered checkpoint does not know its memory was altered, it just continues, confidently, from a false state. Unlike a corrupted database record a human might notice looks wrong, a corrupted agent memory gets interpreted and acted on.

── The fix ──

§ 04 · The fix

Fix 1: Patch immediately, but don't stop there. Updating the library (to langgraph-checkpoint-mongodb 0.3.0 / 1.3.1 and langgraph-store-mongodb 0.4.0 or later, per the advisories) closes the specific disclosed flaw. It does not address the underlying pattern: user- or tool-influenced data flowing into checkpoint queries without validation.

Fix 2: Validate and sanitize anything that touches checkpoint state, not just anything that touches the model. Teams are good about sanitizing what goes into a prompt. Far fewer sanitize what goes into the state layer underneath the prompt, this class of bug is a direct consequence of that blind spot. Coerce identifiers to strings and reject any object payload or $-prefixed key before it reaches a query.

Fix 3: Sign or checksum checkpoints on write, verify on read. If a checkpoint's contents don't match its signature when the agent resumes, treat that as a hard failure, not a warning, halt the run rather than resume from state that might have been tampered with.

Fix 4: Isolate checkpoint stores per-tenant, not per-database. Query-level access controls should not be the only thing standing between one customer's agent state and another's. A compromised query in a shared store should fail closed, not cross tenant boundaries.

── The regression test ──

§ 05 · The regression test

Run an automated check that attempts a set of known NoSQL injection payloads ($gt, $ne, $regex, $where and object payloads) against every checkpoint write and read path in CI, on every deployment, regardless of whether the underlying library has a disclosed CVE at that moment. Waiting for the next disclosure is not a strategy.

§ 06 · What this teaches

Every layer an agent touches is part of its attack surface, not just the model-facing layer. State and memory stores get a fraction of the security attention that prompts and tool permissions get, and these disclosures are exactly why that gap matters, a well-permissioned, well-prompted agent is still vulnerable if the thing holding its memory isn't.

── Checklist ──

§ 07 · Checklist

ORBIRESEARCH