comerc/cve-2025-68664Detailed disclosure of CVE-2025-68664, a critical deserialization vulnerability in LangChain core allowing secret exfiltration and potential RCE via crafted prompts and serialization flows.
Author: Yarden Porat
Cyata Research: LangGrinch Vulnerability in LangChain
Published: https://cyata.ai/blog/langgrinch-langchain-core-cve-2025-68664/
Yesterday LangChain published a critical security advisory for a vulnerability I discovered in langchain-core: CVE-2025-68664 / GHSA-c67j-w6g6-q2cm.
Earlier this year, my research focused on breaking secret managers in our "Vault Fault" work – systems specifically designed as a security boundary around your most sensitive credentials. One finding kept repeating itself: when a platform accidentally processes attacker-controlled data as a trusted structure, that boundary collapses fast. This time the system that "breaks" is not your secret manager. It’s the agent framework that may use them.
Why this vulnerability deserves special attention:
It’s in the core. This is not a tool-specific bug, not an integration edge case, and not "some community package did something weird." The vulnerable APIs (dumps() / dumpd()) reside in langchain-core itself.
The blast radius is enormous. By download volume, langchain is one of the most widely deployed AI framework components worldwide today. As of late December 2025, public package telemetry shows hundreds of millions of installs, with pepy.tech reporting ~847M total downloads and pypistats showing ~98M downloads in the last month.
One prompt can trigger many mechanisms. The most common real-world path here is not "an attacker sends you a serialized blob and you call load()." It’s subtler: LLM outputs can influence fields like additional_kwargs or response_metadata, and these fields can be serialized and later deserialized through normal framework facilities such as streaming logs/events. In simple terms, this means an exploit can be launched by a single text prompt that cascades into an unexpectedly complex internal pipeline.
Before you continue reading, patches have already been released in versions 1.2.5 and 0.3.81. If you are using LangChain in production, this is more complex than it may seem; please update as soon as possible.
LangChain uses a special internal serialization format where dictionaries containing the marker 'lc' represent LangChain objects. The vulnerability was that dumps() and dumpd() did not properly escape user-controlled dictionaries that accidentally included the reserved key 'lc'.
Thus, once an attacker can make a LangChain orchestration loop serialize and later deserialize content including the key 'lc', they can instantiate an unsafe arbitrary object, potentially triggering many attacker-friendly paths.
The advisory lists 12 distinct vulnerable flows that are extremely common in real-world use cases such as standard streaming events, logging, message history/memory, or caching:
The most severe impacts include:
Exfiltration of secrets from environment variables. The advisory notes this happens during deserialization with secrets_from_env=True. Notably, this was the default until yesterday. 🙂
Object instantiation in pre-approved namespaces (including langchain_core, langchain_openai, langchain_aws, langchain_anthropic…), potentially triggering side effects in constructors (network calls, file operations, etc.).
Under certain conditions, instantiation of LangChain objects can lead to arbitrary code execution.
This is classified under CWE-502: Deserialization of Untrusted Data, with a CNA CVSS score of 9.3 (Critical).
On Christmas Eve I was doing the least festive work: looking at serialization code and asking "wait… why is this considered trusted?"
Security research often looks dramatic from the outside. In reality it’s usually careful reading, small hypotheses, and slow accumulation of "that’s odd" moments.
It started the way many things do at Cyata: with a simple question we constantly ask when evaluating AI stacks for real risk:
Where are the trust boundaries in AI applications, and do builders actually know where those boundaries are?
LangChain is a powerful framework, and like most modern frameworks, it has to move complex structured data around: messages, tool calls, streaming events, traces, caches, and "runnables."
Looking through prior research, there was already extensive research on LangChain tools and integrations, but very few findings in the core library.
I started the research by working backwards. Finding interesting places (sinks), then figuring out how an attacker could reach them. Deserialization was an obvious target.
It took me quite a while to find something significant. But after some time I found that, assuming an attacker-controlled deserialization primitive, I could trigger a blind SSRF which could be used to exfiltrate environment variables (to be detailed soon). Since the result was limited to secret exfiltration rather than my primary goal of RCE, I continued auditing deserialization and took my time.
The bug was not a piece of bad code, it was missing code. dumps() simply didn't escape user-controlled dictionaries containing the key 'lc'. Escaping missing in the serialization path, not deserialization.
It's much easier to spot something wrong than to spot something missing, especially when you're auditing load(), not dumps(). In one of the most heavily audited AI frameworks. For two and a half years.
From there the research became a structured exercise:
Identify where untrusted content (mainly arbitrary dictionaries) enters serialization (LLM outputs, prompt injection, user input, external tools, retrieved documents).
Identify when those serialized data are deserialized.
Identify what an attacker can achieve from arbitrary object instantiation.
At that point the core finding was clear enough and actionable for responsible disclosure: there was an escaping gap in dumps() / dumpd() around dictionaries with the 'lc' key.
The advisory later captured what we often see in practice: fields like additional_kwargs and response_metadata can be influenced by LLM output and prompt injection, and these fields can be serialized-deserialized in many flows.
Credit to the LangChain team: the response and follow-up were decisive, not just patching the bug but also tightening defaults that were too permissive for the world we now live in.
The LangChain project decided to award a $4,000 USD bounty for this finding. According to huntr, the platform where LangChain ran its bounty program, this would be the highest amount ever awarded in the project, with bounties until now up to $125.
LangChain serializes certain objects using a structured dictionary format. The key 'lc' is used internally to indicate "this is a serialized LangChain structure," not just arbitrary user data.
This is a common pattern, but it creates a security invariant: Any user data that can contain 'lc' must be handled carefully. Otherwise an attacker can craft a dictionary that "looks like" an internal object and trick the deserializer into granting it meaning.
The patch makes the intention explicit in the updated documentation: during serialization, plain dictionaries containing the key 'lc' are escaped by wrapping them.
This prevents these dictionaries from being confused with actual serialized LangChain objects during deserialization.
