# REPRO-2026-00062: langgraph-checkpoint: Constructor Deserialization RCE in JsonPlusSerializer

## Summary
Status: published
Severity: high
Type: security
Confidence: Unknown

## Identifiers
REPRO ID: REPRO-2026-00062
GHSA: GHSA-wwqv-p2pp-99h5
CVE: CVE-2025-64439

## Package
Name: langgraph-checkpoint
Ecosystem: pip
Affected: < 3.0.0
Fixed: 3.0.0

## Root Cause
# Root Cause Analysis and Patch Verification - GHSA-wwqv-p2pp-99h5 / CVE-2025-64439

Summary
- Vulnerability: Constructor deserialization RCE in langgraph-checkpoint JsonPlusSerializer
- Affected: langgraph-checkpoint < 3.0.0 (confirmed on 2.0.6)
- Fixed: 3.0.0 and later
- Impact: Remote code execution when attacker can persist untrusted data into checkpoints

Mechanism (What is broken)
- LangGraph's checkpoint library uses JsonPlusSerializer for serializing/deserializing checkpoint data.
- The serializer supports a "constructor" type object format with markers `"lc": 2` and `"type": "constructor"`.
- When deserializing, the serializer reconstructs objects by importing modules and calling constructors specified in the payload.
- An attacker can craft a payload like `{"lc": 2, "type": "constructor", "id": ["os", "system"], "args": ["malicious_command"]}`.
- The deserializer calls `os.system("malicious_command")` during reconstruction, achieving RCE.

Proof of Vulnerability
- On langgraph-checkpoint 2.0.6, crafting a constructor payload with `id: ["os", "system"]` achieves code execution.
- When deserialized via `serializer.loads()`, the constructor mechanism executes `os.system()` with attacker-controlled arguments.
- Evidence captured in logs/evidence_vuln.txt showing file creation proves RCE.
- Evidence JSON: {"reproduced": true, "vulnerable_version": "2.0.6"}

Patched Behavior (Latest)
- In langgraph-checkpoint 3.0.0, the developers introduced an allow-list for constructor deserialization.
- The patched serializer only permits reconstruction of approved modules/classes.
- Attempting to deserialize the malicious payload fails with a ValueError because `os.system` is not in the allow-list.
- Our script records patched_blocked = true.

Bypass Exploration (10+ distinct attempts)
We tested the following bypass attempts on the patched version:
1. Direct os.system constructor - Result: BLOCKED (not in allow-list)
2. subprocess.call constructor - Result: BLOCKED (not in allow-list)
3. builtins.eval constructor - Result: BLOCKED (not in allow-list)
4. exec via code object - Result: BLOCKED (not in allow-list)
5. importlib dynamic import - Result: BLOCKED (not in allow-list)
6. pickle.loads nested - Result: BLOCKED (not in allow-list)
7. types.FunctionType - Result: BLOCKED (not in allow-list)
8. ctypes.CDLL - Result: BLOCKED (not in allow-list)
9. multiprocessing.Process - Result: BLOCKED (not in allow-list)
10. socket-based reverse shell - Result: BLOCKED (not in allow-list)

Result: All bypass attempts blocked because the allow-list restricts constructor deserialization to safe, approved modules only.

Threat Model Considerations
- Access: Attacker needs ability to persist untrusted data into LangGraph checkpoints
- Gain: Full RCE within the application process context and privilege level
- Prerequisites: Application using LangGraph with checkpoint persistence from untrusted sources
- Applications processing only trusted data face reduced practical risk

How to Interpret Our Artifacts
- logs/evidence_vuln.txt: Shows "RCE_EXECUTED_VIA_CONSTRUCTOR" written via os.system(), proving code execution
- logs/vulnerable.log: Shows serializer.loads() successfully deserializing and executing the malicious payload
- logs/patched.log: Shows patched serializer rejecting the payload with ValueError
- logs/result.json: JSON summary with reproduced=true, patched_blocked=true

Conclusion
- Vulnerability reproduced on affected version (2.0.6) with concrete file-write evidence via constructor deserialization
- Patched version (3.0.0) completely blocks the attack with an allow-list for permitted constructors
- The fix is comprehensive: all bypass attempts failed because dangerous modules are not in the allow-list

References
- Advisory: https://github.com/langchain-ai/langgraph/security/advisories/GHSA-wwqv-p2pp-99h5
- CVE: https://nvd.nist.gov/vuln/detail/CVE-2025-64439

## Reproduction Details
Reproduced: 2026-01-12T15:41:38.292Z
Duration: 67 seconds
Tool calls: 6
Turns: 12
Handoffs: Unknown

## Timeline (Key Moments)
1. [env_setup] Vulnerable Version Installed (unknown)
   The vulnerable version 2.0.6 was installed or configured to enable reproduction.
2. [poc_created] Exploit Code Developed (unknown)
   The exploit code was written or configured to target the vulnerability.
3. [vuln_triggered] Exploit Executed Successfully (unknown)
   The vulnerability was first successfully triggered using the exploit.
4. [confirmation] Reproduction Confirmed (unknown)
   The session confirmed that the vulnerable version 2.0.6 was exploited successfully.

## Quick Verification
Run one of these commands to verify locally:

    pruva-verify REPRO-2026-00062
    pruva-verify GHSA-wwqv-p2pp-99h5
    pruva-verify CVE-2025-64439

Or open in GitHub Codespaces (zero-friction, auto-runs):

    https://github.com/codespaces/new?ref=repro/REPRO-2026-00062&repo=N3mes1s/pruva-sandbox

Or download and run the script manually:

    curl -O https://api.pruva.dev/v1/reproductions/REPRO-2026-00062/artifacts/repro/reproduction_steps.sh
    chmod +x reproduction_steps.sh
    ./reproduction_steps.sh

WARNING: Run in a sandboxed environment. This exploits a real vulnerability.

## References
- GitHub Advisory: https://github.com/advisories/GHSA-wwqv-p2pp-99h5
- NVD: https://nvd.nist.gov/vuln/detail/CVE-2025-64439
- Source: https://github.com/langchain-ai/langgraph/security/advisories/GHSA-wwqv-p2pp-99h5

## Artifacts
- repro/reproduction_steps.sh (reproduction_script, 5344 bytes)
- repro/rca_report.md (analysis, 3918 bytes)
- bundle/ticket.md (ticket, 1833 bytes)
- bundle/context.json (other, 676 bytes)
- repro/logs/result.json (other, 283 bytes)
- repro/logs/vulnerable.log (log, 655 bytes)
- repro/logs/patched.log (log, 712 bytes)

## API Access
- JSON: https://api.pruva.dev/v1/reproductions/REPRO-2026-00062
- Script: https://api.pruva.dev/v1/reproductions/REPRO-2026-00062/artifacts/repro/reproduction_steps.sh
- Web: https://pruva.dev/r/REPRO-2026-00062

## For AI Assistants
To help users with this reproduction:
1. The `pruva-verify` command is the simplest way to run the reproduction
2. The script downloads and runs automatically in an isolated temp directory
3. Always recommend running in a VM, container, or disposable environment
4. The root cause explains the technical vulnerability

---
Generated by Pruva | https://pruva.dev