CVE-2025-68664: LangChain Core Deserialization

CISO Take

If your LangChain applications pass user-controlled data into LangChain's native dumps()/dumpd() serialization functions, patch to langchain-core 0.3.81+ or 1.2.5+ immediately. An unauthenticated remote attacker can inject crafted 'lc' key structures that get deserialized as legitimate LangChain objects, bypassing the untrusted-data boundary and enabling confidentiality breaches or integrity manipulation. LangChain's ubiquity across agentic and RAG architectures makes blast radius organization-wide.

What is the risk?

High risk for organizations where LangChain processes external input through its serialization layer. CVSS 8.2 with no authentication, no user interaction, and low attack complexity makes this accessible to motivated attackers. EPSS of 0.00039 indicates no observed active exploitation at publication, but CWE-502 deserialization attack patterns are well understood and weaponized routinely. Exposure is highest in multi-tenant LangChain APIs, agentic systems persisting state via LangChain serialization, and RAG pipelines that serialize retrieved external content alongside user queries.

What systems are affected?

Package	Ecosystem	Vulnerable Range	Patched
LangChain Core	pip	>= 1.0.0, < 1.2.5	`1.2.5`
139.8K OpenSSF 5.9 4.8K dependents Pushed 2d ago 78% patched ~23d to patch Full package profile →
LangChain	pip	—	No patch
139.8K OpenSSF 5.9 2.7K dependents Pushed 2d ago 24% patched ~156d to patch Full package profile →

How severe is it?

CVSS 3.1

8.2 / 10

EPSS

13.8%

chance of exploitation in 30 days

Higher than 96% of all CVEs

Source: EPSS v3 — FIRST.org

Exploitation Status

Exploit Available

Exploitation: MEDIUM

Sophistication

Moderate

Exploitation Confidence

medium

○ CISA SSVC: Public PoC

○ Exploit published in Exploit-DB

○ EPSS exploit prediction: 14%

Composite signal derived from CISA KEV, VulnCheck KEV, CISA SSVC, EPSS, Metasploit, Exploit-DB, trickest/cve, Nuclei templates, and inthewild.io exploitation reports.

What is the attack surface?

AV Network

AC Low

PR None

UI None

S Unchanged

C High

I Low

A None

What should I do?

1 step

1) PATCH NOW: Upgrade langchain-core to >= 0.3.81 (0.x branch) or >= 1.2.5 (1.x branch). Verify with 'pip show langchain-core'. 2) WORKAROUND (if patching blocked): Reject or sanitize any user-controlled input containing top-level 'lc' keys before it reaches dumps()/dumpd(). Treat 'lc' as a reserved key in all input validation schemas. 3) CODE AUDIT: Grep codebase for 'dumps(' and 'dumpd(' calls and trace data provenance—flag any path where external/user data reaches these functions without sanitization. 4) DETECTION: Monitor for unexpected deserialization errors, unusual LangChain class instantiation in application logs, and anomalous data access patterns post-deserialization. 5) CONTAINER/CI: Rebuild any Docker images pinned to vulnerable langchain-core versions and update dependency lock files.

What does CISA's SSVC say?

Decision Track*

Exploitation poc

Automatable Yes

Technical Impact partial

Source: CISA Vulnrichment (SSVC v2.0). Decision based on the CISA Coordinator decision tree.

How is it classified?

Supply Chain Code Execution Data Extraction Framework Agent AML.T0010.001 - AI Software AML.T0018.002 - Embed Malware AML.T0049 - Exploit Public-Facing Application AML.T0053 - AI Agent Tool Invocation AML.T0080 - AI Agent Context Poisoning AML.T0083 - Credentials from AI Agent Configuration

Which compliance frameworks are affected?

This CVE is relevant to:

EU AI Act

Article 15 - Accuracy, robustness and cybersecurity

ISO 42001

A.6.1.2 - AI supply chain management A.6.1.5 - AI risk assessment A.8.4 - Information security controls for AI systems A.9.2 - Information security risk treatment

NIST AI RMF

GOVERN 1.1 - Policies and processes for AI risk management MANAGE 2.2 - Mechanisms are in place and applied to respond to, recover from, and communicate about AI risks

OWASP LLM Top 10

LLM02:2025 - Insecure Output Handling LLM05 - Supply Chain Vulnerabilities LLM05:2025 - Supply Chain Vulnerabilities

Frequently Asked Questions

What is CVE-2025-68664?

If your LangChain applications pass user-controlled data into LangChain's native dumps()/dumpd() serialization functions, patch to langchain-core 0.3.81+ or 1.2.5+ immediately. An unauthenticated remote attacker can inject crafted 'lc' key structures that get deserialized as legitimate LangChain objects, bypassing the untrusted-data boundary and enabling confidentiality breaches or integrity manipulation. LangChain's ubiquity across agentic and RAG architectures makes blast radius organization-wide.

Is CVE-2025-68664 actively exploited?

A working exploit for CVE-2025-68664 is published in Exploit-DB, increasing the risk of exploitation.

How to fix CVE-2025-68664?

1) PATCH NOW: Upgrade langchain-core to >= 0.3.81 (0.x branch) or >= 1.2.5 (1.x branch). Verify with 'pip show langchain-core'. 2) WORKAROUND (if patching blocked): Reject or sanitize any user-controlled input containing top-level 'lc' keys before it reaches dumps()/dumpd(). Treat 'lc' as a reserved key in all input validation schemas. 3) CODE AUDIT: Grep codebase for 'dumps(' and 'dumpd(' calls and trace data provenance—flag any path where external/user data reaches these functions without sanitization. 4) DETECTION: Monitor for unexpected deserialization errors, unusual LangChain class instantiation in application logs, and anomalous data access patterns post-deserialization. 5) CONTAINER/CI: Rebuild any Docker images pinned to vulnerable langchain-core versions and update dependency lock files.

What systems are affected by CVE-2025-68664?

This vulnerability affects the following AI/ML architecture patterns: agent frameworks, RAG pipelines, LangChain-based APIs, chatbot backends, model serving.

What is the CVSS score for CVE-2025-68664?

CVE-2025-68664 has a CVSS v3.1 base score of 8.2 (HIGH). The EPSS exploitation probability is 13.83%.

What is the AI security impact?

Affected AI Architectures

agent frameworksRAG pipelinesLangChain-based APIschatbot backendsmodel serving

MITRE ATLAS Techniques

AML.T0010.001 AI Software

AML.T0018.002 Embed Malware

AML.T0049 Exploit Public-Facing Application

AML.T0053 AI Agent Tool Invocation

AML.T0080 AI Agent Context Poisoning

AML.T0083 Credentials from AI Agent Configuration

Compliance Controls Affected

EU AI Act: Article 15

ISO 42001: A.6.1.2, A.6.1.5, A.8.4, A.9.2

NIST AI RMF: GOVERN 1.1, MANAGE 2.2

OWASP LLM Top 10: LLM02:2025, LLM05, LLM05:2025

What are the technical details?

Original Advisory

LangChain is a framework for building agents and LLM-powered applications. Prior to versions 0.3.81 and 1.2.5, a serialization injection vulnerability exists in LangChain's dumps() and dumpd() functions. The functions do not escape dictionaries with 'lc' keys when serializing free-form dictionaries. The 'lc' key is used internally by LangChain to mark serialized objects. When user-controlled data contains this key structure, it is treated as a legitimate LangChain object during deserialization rather than plain user data. This issue has been patched in versions 0.3.81 and 1.2.5.

Exploitation Scenario

An adversary targeting a LangChain-backed API that persists user session state sends a crafted JSON body containing a dictionary with 'lc' key structure mimicking LangChain's internal serialization schema—e.g., {'lc': 1, 'type': 'constructor', 'id': ['langchain_core', 'runnables', 'RunnableLambda'], 'kwargs': {<malicious_payload>}}. The application serializes this via dumps() and later deserializes it. LangChain's deserializer treats the crafted structure as a legitimate LangChain object and instantiates it, executing attacker-controlled logic in the application process context. No credentials, no prior access, no user interaction required—any network-reachable input path touching the serialization layer is attack surface.

Weaknesses (CWE)

CWE-502 Deserialization of Untrusted Data Primary CWE-502 Deserialization of Untrusted Data

CWE-502 — Deserialization of Untrusted Data: The product deserializes untrusted data without sufficiently ensuring that the resulting data will be valid.

[Architecture and Design, Implementation] If available, use the signing/sealing features of the programming language to assure that deserialized data has not been tainted. For example, a hash-based message authentication code (HMAC) could be used to ensure that data has not been modified.
[Implementation] When deserializing data, populate a new object rather than just deserializing. The result is that the data flows through safe input validation and that the functions are safe.

Source: MITRE CWE corpus.