CVE-2026-48775: LangGraph Checkpoint: Unsafe JSON deserialization in checkpoint loading

LangGraph saves graph state as checkpoints and reloads them to resume a run. The default serializer in PostgresSaver, SqliteSaver and their async versions is JsonPlusSerializer, which can revive Python objects from JSON payloads. If an attacker has altered those bytes at rest, the revival path could build objects beyond what the app expects, and that can run code at load time.

The precondition is demanding: write access to the checkpoint store, such as the database, a remote store or a shared filesystem. The CVSS vector reflects it (adjacent network, high privileges, score 6.8). In most deployments that access already means a serious incident. The added risk is escalation from store access to code execution in the LangGraph worker, where runtime secrets and reachable systems are exposed.

LangChain says it knows of no exploitation in the wild and no practical path in current deployments. It also says typical LangSmith-hosted setups prevent such access. Apps that resume from persistent checkpoints with the default serializer are in scope without opting in.

langgraph-checkpoint before 4.1.1 (4.1.0 and earlier). You are in scope if you use a persistent checkpointer with the default JsonPlusSerializer, resume from checkpoints, and the checkpoint store could be written by someone unauthorized.

pip show langgraph-checkpoint

In-memory checkpointers that never leave the process do not have the at-rest exposure.

Upgrade to langgraph-checkpoint 4.1.1.

pip install --upgrade "langgraph-checkpoint>=4.1.1"

The JSON revival path now only rebuilds objects through the default constructor, using the args and kwargs in the payload. Newly written checkpoints are not affected, because the encoder stopped using the removed behavior after the msgpack migration.

One compatibility note: Pydantic model checkpoints written before October 2025 that relied on a no-validation fallback factory now come back as a raw dict, not a model. The advisory also advises restricting write access to the checkpoint store, rotating credentials if access was unauthorized, and avoiding custom JSON revival hooks that rebuild arbitrary types.

Audit who and what can write to your checkpoint tables or files, and review that store's access logs for modifications that do not come from the application. Look for checkpoint rows whose JSON payload contains unfamiliar class paths or constructor references. After a store incident, treat worker processes that loaded checkpoints as potentially compromised and rotate their secrets.

Summary

LangGraph's JsonPlusSerializer can reconstruct Python objects from JSON checkpoint payloads. Under conditions where someone could modify checkpoint bytes at rest in the backing store, the deserialization path could reconstruct objects beyond what the application expects, which could in turn result in code execution at checkpoint load time.

This is a defense-in-depth issue. The affected behavior is reachable only when checkpoint bytes at rest in the backing store can be modified by an unauthorized party. In most deployments that prerequisite already implies a serious incident; the additional concern is turning "checkpoint-store write access" into code execution in the application runtime.

There is no evidence of this behavior being triggered in the wild, and the team is not aware of a practical path to it in existing deployments today. This change is intended to reduce the surface available after a checkpoint-store incident.

Affected users / systems

Users may be affected if they:

• use a persistent checkpointer (database, remote store, shared filesystem, etc.) with the default JsonPlusSerializer,
• load/resume from checkpoints, and
• operate in an environment where write access to the checkpoint store could be obtained by an unauthorized party.

The default checkpoint serializer in all shipped checkpointer backends (PostgresSaver, SqliteSaver, and their async counterparts) is JsonPlusSerializer, so applications generally do not need to opt in to be in scope.

Impact

• Potential arbitrary code execution or other unsafe side effects during checkpoint deserialization.
• Escalation from "write access to the checkpoint store" to "code execution in the LangGraph worker process," which may expose runtime secrets or provide access to other systems the runtime can reach.

Patches / mitigation

The JSON deserialization path has been narrowed so that revival is restricted to default-constructor reconstruction using the args/kwargs carried in the payload. The framework's own encoder has not relied on the removed behavior for produced checkpoints since the msgpack migration, so this change does not affect freshly written checkpoints. Legacy payloads that already used the default constructor as their first option continue to revive correctly via that same path.

Compatibility

A narrow legacy-resume regression applies to pre-October-2025 checkpoints of pydantic models where the original payload depended on a no-validation fallback factory to recover from incompatible schema evolution. After this change, such payloads return None from the revival path and fall through to the langchain-core reviver, which surfaces the raw dict rather than reconstructing the model.

Operational guidance

• Treat checkpoint stores as integrity-sensitive. Restrict write access and rotate credentials if unauthorized access is suspected.
• Avoid providing custom JSON revival hooks that reconstruct arbitrary types unless checkpoint data is fully trusted.

LangSmith / hosted deployments note

The team is not aware of this issue presenting concern for existing LangSmith-hosted deployments. The described conditions require modification of the checkpoint persistence layer used by the deployment; typical hosted configurations are designed to prevent such access.

First reported by: pucagit (CyStack).