CVE-2025-68664: When User Input Masquerades as Trusted LangChain Objects

Overview

CVE ID: CVE-2025-68664
Affected Product: LangChain
Vulnerability Type: Serialization Injection / Trust Boundary Bypass

Affected Versions:

All versions prior to 0.3.81 (0.x release line)
All versions prior to 1.2.5 (1.x release line)

CVSS v3.1 Base Score: 8.1
Severity: High

Attack Vector: Remote
Attack Complexity: Low
Privileges Required: None
User Interaction: None
Scope: Changed
Impact: Integrity & Availability (with potential Confidentiality impact depending on implementation)

Exploitability: High (easy to abuse in real-world apps)
Exploit Availability: No public exploit published, but exploitation logic is trivial
Patch Available: Yes (official upstream fix)

Executive Summary

CVE-2025-68664 is a high-risk serialization injection vulnerability in LangChain that affects how application data is converted to and from serialized formats. The issue stems from LangChain’s internal use of a reserved dictionary key named "lc", which is meant to identify framework-owned serialized objects.

In vulnerable versions, LangChain does not properly escape or protect this key when handling free-form user dictionaries. As a result, attacker-controlled input can masquerade as a trusted LangChain object during deserialization.

This breaks a fundamental security boundary between user data and framework internals and can lead to unexpected object creation, logic manipulation, or unsafe execution paths inside LLM-powered applications.

Technical Root Cause

LangChain provides helper functions such as:

dumps()
dumpd()

These functions serialize Python objects into structured formats (typically JSON-like dictionaries). Internally, LangChain uses a special marker key called "lc" to tag objects that belong to its own ecosystem (chains, tools, agents, memory objects, etc.).

The Core Problem

LangChain assumes that dictionaries containing "lc" were generated internally
However, user-provided dictionaries are not sanitized
When user input includes an "lc" key with the expected structure, LangChain:
- Treats it as a legitimate internal object
- Applies privileged deserialization logic
- Skips normal safety assumptions made for user data

This is a classic trust confusion issue caused by mixing internal metadata with external input.

How This Vulnerability Can Be Exploited

Any LangChain application is vulnerable if it does all of the following:

Accepts user-controlled structured input (JSON, dicts, configs, memory objects, etc.)
Uses dumps() or dumpd() to serialize that input
Later deserializes the data (locally, across sessions, or between services)

Realistic Exploitation Flow

An attacker submits crafted input containing an "lc" key
The application serializes it without validation
During deserialization, LangChain interprets the payload as a framework object
Internal logic meant only for trusted components is executed

Why This Is Dangerous

Depending on how LangChain is used, this can lead to:

Creation of unintended chain, tool, or memory objects
Manipulation of agent decision logic
Unauthorized invocation of tools or functions
Application crashes or infinite loops (DoS)
In advanced deployments, execution of unsafe code paths

This is especially risky in:

Agent-based systems
Tool-calling workflows
Stateful memory or checkpointing setups
Multi-tenant or API-driven LLM services

Proof of Concept (PoC) Status

No public exploit code released
Vulnerability is easy to reproduce
Requires no authentication
No race conditions or special timing needed

From a defender’s point of view, lack of a public PoC does not reduce risk, as exploitation only requires knowledge of LangChain’s internal serialization format.

Example Malicious Payload

Below is a simplified example of how attacker-controlled input could abuse the vulnerability:

{
  "query": "summarize my data",
  "lc": {
    "type": "langchain_object",
    "id": "InjectedChain",
    "kwargs": {
      "steps": ["unexpected", "logic", "execution"]
    }
  }
}

In vulnerable versions, this payload may be deserialized as a valid LangChain object, even though it originated entirely from user input.

Detection & Threat Hunting Guidance

Key Indicators to Watch For

Incoming JSON or dictionary payloads containing:
- Top-level "lc" keys
- Nested "lc" structures inside user data
Deserialization errors referencing:
- Unexpected LangChain object types
- Invalid or unknown internal IDs
Application behavior that changes without code deployment

Detection Rules (Conceptual Examples)

While exact rules depend on your environment, defenders should consider:

Flagging serialized data where "lc" appears outside known safe contexts
Alerting when deserialization results in:
- Objects not explicitly allowed by application logic
- Chains or tools that were never registered
Blocking or rejecting user input containing reserved internal keys

Recommended Log Sources

To effectively detect or investigate abuse attempts, ensure visibility into:

Application logs
- Serialization and deserialization activity
- Agent lifecycle events
- Tool execution traces
API Gateway / Reverse Proxy logs
- Raw request payloads
- Anomalous structured inputs
Security & Runtime Monitoring
- Exceptions tied to LangChain internals
- Unexpected object instantiation events

MITRE ATT&CK Mapping

This vulnerability aligns with the following ATT&CK techniques:

T1190 – Exploit Public-Facing Application
T1059 – Command and Scripting Interpreter (conditional, based on downstream execution)
T1609 – Container Administration Command (in agent/tool-based architectures)

Remediation & Mitigation

Official Fix (Strongly Recommended)

Upgrade immediately to one of the patched versions:

LangChain 0.3.81 or later
LangChain 1.2.5 or later

Official Patch Link:
https://github.com/langchain-ai/langchain/releases

Additional Defensive Measures

Even after patching, it is recommended to:

Treat all serialized input as untrusted
Explicitly validate schemas for incoming dictionaries
Block reserved internal keys ("lc", metadata markers, etc.) in user input
Avoid deserializing user data unless absolutely necessary
Implement allowlists for valid object types
Add monitoring around deserialization logic

Final Assessment

CVE-2025-68664 is a serious design-level vulnerability, not a simple coding mistake. It highlights the risks of blending framework metadata with user input in dynamic, AI-driven systems.

Because LangChain is widely used in production LLM applications, this issue should be treated as a priority security update, especially in environments that expose APIs, accept external input, or run autonomous agents.

If LangChain is part of your production stack and has not yet been updated, you are operating with a real and avoidable risk.