CVE-2025-68664: Critical LangChain Flaw Enables Secret Extraction

A recently disclosed security issue in LangChain Core, CVE-2025-68664, has drawn attention across the AI and developer communities, particularly among teams building applications on top of Large Language Models (LLMs). The vulnerability affects how LangChain serializes and deserializes data, opening the door to secret leakage and unintended object instantiation when untrusted input is involved.

This blog aims to explain what the vulnerability is, how it works, who is affected, what the real-world risks look like, and what actions developers should take next.

What Is CVE-2025-68664?

CVE-2025-68664 (CVSS 9.3) is a serialization injection vulnerability in LangChain Core’s dumps() and dumpd() functions, as detailed in the advisory. These functions are responsible for converting Python objects into a serialized format that can later be reconstructed using load() or loads().

The problem arises because user-controlled dictionaries containing a specific internal marker key (“lc”) were not properly escaped. As a result, data that should have been treated as plain user input could be interpreted as a trusted LangChain object during deserialization instead.

CVE-2025-68664 (SOCRadar Vulnerability Intelligence)

Why Does the “lc” Key Matter in Serialization?

LangChain uses the “lc” key internally to identify serialized framework objects. During deserialization, the presence of this key signals that the data represents a structured LangChain object rather than arbitrary input.

Because the vulnerable functions did not neutralize this marker in free-form dictionaries, attackers could craft inputs that masquerade as legitimate objects. This breaks the boundary between untrusted data and trusted internal logic.

How Can CVE-2025-68664 Be Exploited in Practice?

Research has shown how attacker-controlled LLM outputs can be serialized and later abused during deserialization, expanding the practical impact of the vulnerability. Exploitation becomes possible when applications serialize and later deserialize data that includes user-influenced content. Common examples include:

• LLM response fields, such as additional_kwargs or response_metadata
• Metadata passed through orchestration or streaming APIs
• Cached or stored generations, later reloaded into memory

In these scenarios, an attacker could inject serialized structures that trigger unsafe behaviors during deserialization, without needing direct code execution access.

What Are the Potential Security Impacts?

The most significant risks include:

• Secret extraction from environment variables, especially in setups where secret loading from the environment was previously enabled by default
• Instantiation of trusted LangChain classes with attacker-controlled parameters, potentially triggering side effects like network requests or file operations
• Prompt injection amplification, where malicious model outputs influence downstream logic through serialization paths

While class instantiation was already limited to trusted namespaces, the combination of serialization trust and LLM-controlled inputs makes this issue particularly sensitive.

SOCRadar’s Vulnerability Intelligence

For security teams tracking emerging risks in open-source and AI ecosystems, vulnerability intelligence capabilities of SOCRadar can help surface critical issues early and map them to affected assets. Through its Cyber Threat Intelligence and Attack Surface Management modules, SOCRadar enables continuous CVE monitoring, asset-level exposure mapping, and prioritization based on real-world risk signals.

Who Is Affected by This Issue?

Applications are at risk if they deserialize data that is not fully trusted. This includes systems that:

• Stream LLM outputs using older event or logging APIs
• Store and reload serialized LangChain objects
• Process user-influenced metadata or cached generations
• Load external or shared LangChain manifests and documents

While CVE-2025-68664 specifically targets the Python package (langchain-core), the broader LangChain ecosystem is also affected: a closely related serialization escaping issue in LangChain.js has been assigned CVE-2025-68665 (CVSS 8.6).

CVE-2025-68665 impacts the JavaScript/TypeScript packages including @langchain/core and langchain across certain version ranges, so teams running mixed stacks (Python services + JS frontends or workers) should review both dependency trees.

CVE-2025-68665 (SOCRadar Vulnerability Intelligence)

Affected Versions

Versions affected by CVE-2025-68664 (Python – langchain-core):

• >= 1.0.0 and < 1.2.5
• < 0.3.81

Packages and versions affected by CVE-2025-68665 (JavaScript / TypeScript – LangChain.js):

• @langchain/core >= 1.0.0, < 1.1.8 (fixed in 1.1.8)
• @langchain/core < 0.3.80 (fixed in 0.3.80)
• langchain >= 1.0.0, < 1.2.3 (fixed in 1.2.3)
• langchain < 0.3.37 (fixed in 0.3.37)

Teams running LangChain in production should confirm that all deployed services fall outside these vulnerable ranges.

What Changes Were Introduced in the Security Patch?

To address CVE-2025-68664, the LangChain maintainers fixed the escaping behavior in dumps() and dumpd() and then tightened deserialization defaults in load() and loads() to reduce the blast radius if untrusted data slips through.

Key security hardening changes include:

• A deserialization allowlist that limits which classes can be reconstructed (via an allowed_objects parameter)
• Environment-based secret loading disabled by default (the secrets_from_env default changed to False)
• Jinja2 template execution blocked unless explicitly allowed (to reduce the risk of template-based code execution)

These are security-driven changes and may be breaking for some advanced or custom serialization use cases, so it’s worth validating any workflows that deserialize non-standard objects.

What Should Developers Do Now?

If you use LangChain Core, treat CVE-2025-68664 as a priority patch. Upgrade to a fixed version and then audit any code paths where untrusted input (including LLM outputs) can be serialized and later deserialized.

A practical checklist:

• Upgrade dependencies to patched releases for both ecosystems you use.
• Search your codebase for dumps(), dumpd(), load(), loads(), and any streaming/logging features that may serialize LLM outputs.
• Assume LLM metadata is attacker-influenced when prompt injection is possible, especially in fields like additional_kwargs and response_metadata.
• Keep deserialization restrictive: only expand allowed_objects when you fully trust the serialized data source.
• Avoid enabling secret loading broadly unless it’s required and you have strong trust guarantees.

CVE-2025-68664 is a reminder that deserialization boundaries matter in AI applications: even when you “only” process model outputs, the surrounding orchestration and data handling layers can become security-critical.

SOCRadar’s Attack Surface Management (ASM) modules

From a broader defense perspective, continuously monitoring newly disclosed vulnerabilities, affected versions, and downstream exposure is essential. The SOCRadar XTI platform helps organizations stay ahead by correlating CVEs, like CVE-2025-68664 and CVE-2025-68665, with real-world attack surface data, enabling faster prioritization and remediation.