LangChain Security Vulnerabilities: Every CVE Worth Patching, and What to Upgrade To

The LangChain vulnerabilities worth acting on today are CVE-2025-68664, a CVSS 9.3 serialization flaw that turns prompt injection into code execution, fixed in langchain-core 0.3.81 or langchain 1.2.5; CVE-2025-64439, remote code execution through LangGraph checkpoint deserialization, fixed in langgraph-checkpoint 3.0; CVE-2026-34070, a CVSS 7.5 path traversal that reads arbitrary files including .env files and SSH keys, fixed in langchain-core 1.2.22; and CVE-2025-67644, SQL injection in the LangGraph SQLite checkpoint backend, fixed in langgraph-checkpoint-sqlite 3.0.1. Because LangChain ships as seven or more independently versioned packages, upgrading the top-level library does not necessarily move the one that is vulnerable.

The Cloud Security Alliance collected these in a research note published March 29, 2026. What follows is the patch matrix, then the part that matters more: two of these are not really dependency bugs, and no upgrade closes them.

The LangChain and LangGraph CVE list

Versions in the last column are the first fixed release. Anything below is affected.

The spread of CVSS scores on CVE-2024-8309 is not a data error. NVD rated it 9.8, the vendor rated it 4.9, and GitHub rated it 2.1, because they disagree about whether a feature that requires an explicit opt-in flag called allow_dangerous_requests counts as a vulnerability. It is a reasonable disagreement, and a good reminder to read what a CVE actually requires before either panicking or ignoring it.

Why a serialization bug got a 9.3

CVE-2025-68664 is the one to fix first, and the score deserves an explanation because "improper handling of special dictionary keys during deserialization" sounds like a parsing nit.

The chain works like this. LangChain serializes and deserializes objects as it moves data through a chain, and applications routinely deserialize content that originated in an LLM response. The flaw is that user-controlled input is not escaped during that round trip, so specially crafted keys can cause the deserializer to instantiate classes it was never meant to touch. Combine that with the fact that a language model can be talked into emitting arbitrary text, and the path is: attacker plants an instruction in something the agent reads, the model emits the payload, the application deserializes it, and code runs in your process. That is why a serializer bug carries the same severity as a remote shell. The escalation is short, and the entry point is text.

Affected versions are langchain-core before 0.3.81 and langchain 1.0.0 through 1.2.4. Both branches were patched, so a team on the 0.3 line does not have to jump to 1.x to be safe.

The LangGraph checkpoint problem

Two of the nine sit in LangGraph's checkpointing layer, and they belong together because they point at the same overlooked asset. A LangGraph agent persists its state so it can pause, wait for a human, resume, and survive a restart. That state contains conversation history, intermediate reasoning, and frequently credentials or session tokens the agent picked up along the way, and it is written to SQLite, Postgres, or Redis.

CVE-2025-64439 makes reading that state dangerous: the JsonPlusSerializer fallback mode permitted dynamic import, so deserializing checkpoint data could execute code. CVE-2025-67644 makes the store itself reachable: metadata filter keys in the SQLite backend were interpolated into SQL, giving an attacker arbitrary queries against exactly the table holding those histories and tokens.

Patch both, then treat the checkpoint store as what it is, a database of session data. It deserves the same access controls, network isolation, and retention policy you would give any store holding user conversations. Most teams we talk to had never classified it at all, because it arrived as an implementation detail of a framework feature rather than as a decision anyone made.

Which LangChain packages do I need to check?

All of them, separately, because they version independently and a top-level upgrade does not pull the others forward. The minimum list is langchain-core, langchain, langgraph, langgraph-checkpoint, langgraph-checkpoint-sqlite, langchain-community, langchain-experimental, and every provider integration you install such as langchain-openai or langchain-anthropic.

Two of those deserve specific attention. langchain-community is where the largest share of historical disclosures lives, because it holds hundreds of loaders and integrations maintained at wildly varying levels of care. If you pulled it in for one loader, check whether you still need the package or just that loader.

langchain-experimental is the sharper one. LangChain's own bug bounty program explicitly excludes it from scope, along with example code and the LangSmith repositories. That is the maintainers drawing a line, and it is worth taking literally: a package outside the security program should not be in a production lockfile. CVE-2024-21513, the eval injection, lived there.

Set up dependency monitoring per package rather than per project. Dependabot or Snyk will do it, and the CSA note makes the same recommendation. The failure mode without it is not that nobody patches, it is that somebody patches langchain, sees the CVE marked resolved, and never learns that langchain-core stayed pinned three minor versions back.

Is LangChain safe to use in production?

Yes, on the same terms as any widely used framework: patched, pinned, monitored, and run with permissions scoped to the task. The CVE count looks alarming in a list, but nine disclosures across seven packages over two years is unremarkable for a library at this level of adoption, and every serious one has a fix. A patched LangChain deployment is not the risk.

What people usually mean by the question is different, and it is worth separating. They are not asking whether the library has bugs. They are asking whether an autonomous agent with production credentials is safe to run, and that question does not change when you patch. LangChain's own security policy is refreshingly direct about it: limit permissions, anticipate misuse, and layer defenses, because "no security technique is perfect." The policy also tells you to assume that if credentials permit deletion, the model might delete. That is not a caveat about bugs. It is a description of how the system works.

The vulnerability that patching does not fix

Look again at the last row of the table. CVE-2025-46059 is indirect prompt injection through the Gmail toolkit: an agent reads an email, the email contains instructions, the agent follows them, and its credentials are compromised. The recommended mitigation is not a version number. It is "treat external content as untrusted input," which is an architectural instruction, because there is no code change to the toolkit that makes a model reliably ignore an instruction written in the same language as its task.

That class of risk grows with every content source you connect. Email is one. A vector store is another, and an index that ingests documents from outside the company is an injection surface by construction. So is any agent that browses the web and pulls pages back as text, which is now a common pattern given how easy it is to have an agent browse a site and return structured data. In each case the content arrives looking exactly like the content the agent is supposed to read, because it is. We go through the mechanics on indirect prompt injection.

CVE-2025-68664 shows the two halves interacting. Patching removes the escalation from injection to code execution, which is a real and important reduction. It does not remove the injection. After the upgrade, an attacker who plants an instruction in a retrieved document can no longer run code in your process, but the agent will still do whatever its tools and credentials permit, which in most deployments is a great deal. The severity dropped. The attack still works.

The control for that half has to sit outside the agent process, on the path between the decision and the action. It inspects untrusted content wherever it enters rather than only at the front door, checks each tool call against permissions granted to that specific agent, holds irreversible actions for a human, and records every verdict. LangChain's middleware layer is a good place for the fast in-loop checks and we recommend using it, but it is application code inside the same trust boundary as the agent, opt-in per agent, and changed by whoever ships the next release. Defense in depth, which LangChain's own policy asks for, means at least one layer that a developer cannot quietly remove. The full picture is on our LangChain security page, and the specific mechanics are in tool permissions and prompt injection detection.

What to do this week

1. Print the resolved versions of every LangChain package in every production lockfile, not the ranges in your manifest. Compare against the fixed-in column above.
2. Upgrade langchain-core first. It carries two of the four most serious issues and it is the package most likely to be lagging.
3. Search for langchain-experimental. If it appears anywhere production-facing, plan its removal, because it sits outside LangChain's own security program.
4. Classify your LangGraph checkpoint store as session data and give it the access controls that implies.
5. Enable per-package dependency alerts, so the next disclosure reaches you without someone reading a research note.
6. Then, separately, write down what each agent can actually reach through its credentials and tool list. That list is your real exposure, and no CVE feed will tell you about it. If code execution is part of the job, sandboxing comes before anything else on this list.

Steps one through five are an afternoon and they close every issue in the table. Step six is the harder one, and it is the one that still matters after the next patch cycle.