CVE-2026-48775: LangGraph SQLite Checkpoint Unsafe Deserialization

Technical summary

The vulnerability exists in LangGraph's JsonPlusSerializer, which deserializes Python objects from JSON-formatted checkpoint payloads. The vulnerable code path permits reconstruction of arbitrary Python objects during checkpoint loading (both synchronous and asynchronous via aiosqlite). An attacker with write-level access to the SQLite database file can craft malicious serialized objects that trigger code execution when deserialized. The root cause is unsafe deserialization (CWE-502) combined with inadequate object validation (CWE-913). Mitigation is applied in version 4.1.1 through changes to the serialization/deserialization logic.

Business impact

Organizations using LangGraph checkpoints risk escalation of storage-layer compromise into application-level code execution. If an attacker breaches file-system or database permissions protecting checkpoint data, they can pivot to running arbitrary code within application processes. This undermines the separation between data layer and application layer, potentially exposing sensitive data, enabling lateral movement, or disrupting service availability. Teams relying on checkpoint durability and replay for LLM applications should treat this as a privilege-escalation vector.

Affected systems

LangGraph Checkpoint versions 4.1.0 and earlier are affected. The vulnerability applies to both synchronous and asynchronous (aiosqlite) implementations of SQLite-backed checkpointing. Any application using LangGraph's CheckpointSaver with SQLite as the backing store is at risk if the storage location is accessible to unauthorized parties or if administrative credentials are compromised.

Exploitability

Exploitation requires two preconditions: (1) an attacker must first gain write access to the SQLite checkpoint database file, and (2) the application must load a checkpoint at runtime. The CVSS vector (AV:A/AC:L/PR:H) reflects that this is an adjacent-network or local threat requiring high privilege. However, in cloud and containerized deployments, storage access may be less tightly controlled than intended, and insider threats or credential compromise are realistic. Once storage write access is obtained, crafting a malicious checkpoint is straightforward—the serialization format is well-documented and Python's deserialization is deterministic.

Remediation

Upgrade LangGraph Checkpoint to version 4.1.1 or later. This version removes unsafe deserialization of arbitrary Python objects. After patching, review file-system and database permissions for checkpoint storage to ensure only the application process and authorized administrators can write to checkpoint files. Consider encrypting checkpoint files at rest and in transit, enforcing least-privilege access controls, and monitoring for unauthorized modifications to checkpoint storage.

Patch guidance

Verify the installed version of LangGraph Checkpoint and update to 4.1.1 or later. For most Python environments, this can be done via pip: `pip install --upgrade langgraph-checkpoint>=4.1.1`. Applications should test checkpoint compatibility before and after the upgrade, particularly if custom serializers or checkpoint migration logic is in use. Review release notes for version 4.1.1 to confirm behavior changes relevant to your deployment.

Detection guidance

Monitor for unexpected modifications to SQLite checkpoint database files or unexpected access patterns (writes) to checkpoint storage. Log and alert on deserialization failures or exceptions during checkpoint load operations, which may indicate attempts to inject malicious payloads. Audit file-system and database permissions on checkpoint directories to ensure they match your intended access model. If feasible, use file integrity monitoring (FIM) tools to detect tampering with checkpoint files.

Why prioritize this

Although this is a MEDIUM-severity vulnerability with a CVSS score of 6.8, it warrants prompt attention because it represents a privilege escalation from storage access to code execution. Applications handling sensitive data or running in multi-tenant environments should prioritize patching. The vulnerability is not listed in the KEV catalog, indicating limited evidence of active exploitation in the wild, but that should not delay remediation—the attack chain is simple once storage access is obtained. Organizations should schedule patching within standard maintenance windows but do not need to treat this as an emergency.

Risk score, explained

The CVSS 3.1 score of 6.8 (MEDIUM) reflects a local or adjacent-network attack vector (AV:A), low attack complexity (AC:L), and high privilege requirement (PR:H), balanced against high impact on confidentiality, integrity, and availability (C:H/I:H/A:H). The score appropriately captures the two-stage nature of the attack—storage compromise must precede exploitation—but underweights the severity of the impact (arbitrary code execution) in some organizational contexts. Teams handling high-value data or running applications with strict security postures may warrant treating this as functionally HIGH priority despite the MEDIUM score.

Frequently asked questions