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`
148.8KOpenSSF 5.76.3K dependentsPushed 5d ago78% patched~44d to patchFull package profile →
LangChain	pip	—	No patch
148.8KOpenSSF 5.73.2K dependentsPushed 5d ago30% patched~164d to patchFull package profile →

How severe is it?

CVSS 3.1

8.2 / 10

EPSS

42.9%

chance of exploitation in 30 days

Higher than 99% 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: 43%

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?

AVNetwork

ACLow

PRNone

UINone

SUnchanged

CHigh

ILow

ANone

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?

DecisionTrack*

Exploitationpoc

AutomatableYes

Technical Impactpartial

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

How is it classified?

Supply ChainCode ExecutionData ExtractionFrameworkAgentAML.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 managementA.6.1.5-AI risk assessmentA.8.4-Information security controls for AI systemsA.9.2-Information security risk treatment

NIST AI RMF

GOVERN 1.1-Policies and processes for AI risk managementMANAGE 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 HandlingLLM05-Supply Chain VulnerabilitiesLLM05: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 42.93%.

What is the AI security impact?

Affected AI Architectures

agent frameworksRAG pipelinesLangChain-based APIschatbot backendsmodel serving

MITRE ATLAS Techniques

AML.T0010.001AI Software

AML.T0018.002Embed Malware

AML.T0049Exploit Public-Facing Application

AML.T0053AI Agent Tool Invocation

AML.T0080AI Agent Context Poisoning

AML.T0083Credentials 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-502Deserialization of Untrusted DataPrimary CWE-502Deserialization 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.