LangChain and LangGraph carried three disclosed CVEs as of March 2026 — a path-traversal flaw, a critical deserialization bug, and a SQL injection in LangGraph's checkpoint store — that together let an attacker read arbitrary files, exfiltrate environment secrets, and manipulate conversation-history queries. If your deployment predates the March 2026 patch cycle, this is the first thing to check before anything else in this post.
What happened
Security researcher Vladimir Tokarev at Cyera disclosed three separate vulnerabilities across the LangChain ecosystem on 27 March 2026, characterizing them as "three independent paths" to drain sensitive data — filesystem contents, environment secrets, and conversation histories — from any enterprise LangChain deployment (The Hacker News, 27 Mar 2026). One of the three, "LangGrinch," had actually first been flagged by Cyata in December 2025 before being formally CVE-assigned and re-covered in the March wave.
The scale matters as much as the severity. LangChain, LangChain-Core, and LangGraph together see 52M+, 23M+, and 9M+ weekly downloads respectively (The Hacker News, 27 Mar 2026). A vulnerability class that ships to that many installs by default is a supply-chain event for the agent ecosystem, not an isolated bug report — the same reasoning that applies to any widely-vendored open-source dependency now applies squarely to agent orchestration frameworks.
As of late August 2026, this remains the reference framework-security incident for LangChain and LangGraph, five months on from disclosure.
The three CVEs
Each of the three targets a different layer of a typical LangChain/LangGraph deployment: prompt loading, object deserialization, and checkpoint persistence.
| CVE | Component | CVSS | What it allows |
|---|---|---|---|
| CVE-2026-34070 | LangChain prompt-loading API | 7.5 | Path traversal — access to arbitrary files without validation via a crafted prompt template |
| CVE-2025-68664 ("LangGrinch") | LangChain deserialization | 9.3 | Leaks API keys and environment secrets through unsafe deserialization |
| CVE-2025-67644 | LangGraph SQLite checkpoint implementation | 7.3 | SQL injection via metadata filter keys, manipulating checkpoint queries |
CVE-2026-34070 sits in LangChain's prompt-loading API. A crafted prompt template can traverse outside the intended directory and pull arbitrary files off the host — no input validation stands between the template path and the filesystem read (The Hacker News, 27 Mar 2026).
CVE-2025-68664, the highest-severity of the three at CVSS 9.3, is a deserialization vulnerability that leaks API keys and environment secrets. It was the first of the three publicly flagged, by Cyata in December 2025, months before it carried a formal CVE identifier — a reminder that community disclosure and formal CVE assignment can run on very different timelines (The Hacker News, 27 Mar 2026).
CVE-2025-67644 is the LangGraph-specific entry: a SQL injection in LangGraph's SQLite checkpoint implementation. LangGraph persists agent state — the running conversation and execution graph — as checkpoints, and this flaw lets an attacker manipulate the underlying SQL queries through metadata filter keys, rather than through the checkpoint content itself (The Hacker News, 27 Mar 2026).
What can go wrong when these stack
Read individually, each CVE looks bounded — a file read here, a secret leak there. Read together, Tokarev's framing is the useful one: three independent paths converging on the same category of outcome, sensitive data leaving a production agent deployment (The Hacker News, 27 Mar 2026).
A realistic chain: an attacker who can influence a prompt template (directly, or indirectly through content the agent ingests) uses the path-traversal flaw to read configuration files off the host. Those files often contain, or point to, the same environment secrets the deserialization bug can leak directly — API keys for the LLM provider, database credentials, third-party service tokens. Separately, if the deployment uses LangGraph's SQLite checkpointing to persist multi-turn agent state, the SQL injection gives an attacker a second, independent route into stored conversation history — including whatever the agent discussed with legitimate users, potentially spanning sessions.
None of the three requires the attacker to have valid credentials to the application first. That is what elevates this from "a bug in a library" to a framework-level trust problem: the vulnerable surface is the orchestration layer itself, sitting underneath whatever authentication the application built on top of it.
Why framework-level CVEs are a distinct risk class from runtime prompt injection
It's worth being precise about what kind of vulnerability this is, because the fix and the mitigation differ from the runtime threats most agent-security content focuses on. Indirect prompt injection is a runtime problem: an agent processes untrusted content and gets manipulated into taking an unintended action, and the defense is layered detection and least-privilege scoping applied continuously, session by session. A framework CVE like the three above is a supply-chain problem: the vulnerability exists in the orchestration code itself, independent of what any individual agent does at runtime, and the fix is a version bump, not a behavioral control.
That distinction matters for how a team should triage exposure. A runtime prompt-injection control (content scanning, output validation) does nothing to close CVE-2026-34070's path-traversal hole — the flaw is in how the prompt-loading API resolves file paths, not in what a malicious prompt asks the agent to do. Conversely, patching the framework does nothing to stop a legitimate, unpatched agent from being manipulated by injected content at runtime. Both categories of control are necessary, and treating a framework patch as if it covers runtime risk (or vice versa) leaves a gap either way.
Controls a platform team should apply
The single highest-leverage action is also the simplest: confirm your pinned versions. The patched releases are langchain-core ≥1.2.22 (also backported to 0.3.81 and 1.2.5) and langgraph-checkpoint-sqlite 3.0.1 (The Hacker News, 27 Mar 2026). If your lockfile predates these, treat it as an active exposure, not a hygiene item for the next sprint.
Beyond the patch itself, three structural controls reduce exposure to this entire class of framework-level vulnerability, independent of which specific CVE is in play:
- Track framework dependencies like any other supply-chain risk. Agent orchestration frameworks now sit in the same trust position as web frameworks or serialization libraries did a decade ago — pin versions, subscribe to security advisories for the specific packages in your dependency tree, and treat a framework CVE as a production incident, not a documentation update.
- Scope what the checkpoint store — or any persistence layer — can expose. A checkpoint database that holds full conversation history is a high-value target by design. Isolating it from broader network access and encrypting it at rest limits what a successful injection can retrieve even before the underlying bug is patched. The same logic that governs MCP server security — classify data by sensitivity, don't trust the default configuration — applies directly to checkpoint stores.
- Validate untrusted content before it reaches a prompt template. CVE-2026-34070 is exploitable through a crafted prompt template; the deeper pattern is the same one behind indirect prompt injection — content an agent processes can carry structure the framework did not anticipate. Input-side scanning and template validation are complementary to patching, not a substitute for it.
For teams building or operating agents with LangChain or LangGraph as the orchestration layer, these three controls sit alongside the broader identity, authorization, and audit-logging controls covered in the AI agent security guide — framework patching handles one class of risk; the surrounding controls handle what happens if a future, unpatched flaw is exploited before a fix ships.
Frameworks with community-contributed extensions carry an adjacent risk worth flagging here too: an agent's dependency tree can include third-party packages with far less scrutiny than the core framework itself, a supply-chain pattern also documented for Agent Skills — vet what you pull in, not just what ships from the framework maintainer.
FAQ
Is LangChain still safe to use in production after these CVEs? Yes, if patched. The vulnerable versions predate the March 2026 fixes; deployments running langchain-core ≥1.2.22 (or the 0.3.81 / 1.2.5 backports) and langgraph-checkpoint-sqlite 3.0.1 are not exposed to these three specific issues.
Which CVE is most urgent to patch? CVE-2025-68664 ("LangGrinch," CVSS 9.3) is the highest severity — it directly leaks API keys and environment secrets — but all three should be treated as one patch cycle, since fixes ship together.
Does this affect LangGraph's checkpointing feature specifically, or all of LangGraph? Only CVE-2025-67644 is LangGraph-specific, and it's scoped to the SQLite checkpoint implementation's handling of metadata filter keys — not every LangGraph deployment or persistence backend is implicated.