Overview

CVE ID: CVE-2025-68665
Product: LangChain (JavaScript / TypeScript ecosystem)
Affected Area: Object serialization and deserialization (toJSON() and JSON.stringify())
CVSS v3.1 Score: 8.1
Severity: High
Attack Vector: Network
Attack Complexity: Low
Privileges Required: None
User Interaction: Required (attacker-controlled input must be processed)
Exploitability: High
Exploit Availability: No public exploit published, but exploitation is practical and low effort

Overview

CVE-2025-68665 is a serialization injection vulnerability affecting LangChain JS. The issue exists in how LangChain serializes and deserializes objects using its internal toJSON() method and when objects are later converted using JSON.stringify().

LangChain uses a special internal marker key named lc to identify objects that belong to its own internal serialization format. Prior to the fixed versions, LangChain did not properly escape or sanitize user-controlled data containing this key when handling free-form keyword arguments (kwargs). As a result, user-supplied objects that included an lc key were mistakenly treated as trusted LangChain objects during deserialization.

This breaks the trust boundary between internal framework data and external user input.

Technical Root Cause

Internally, LangChain relies on structured JSON objects with reserved keys such as:

• lc
• id
• type
• kwargs

These keys allow LangChain to reconstruct complex objects such as chains, runnables, tools, or sequences during deserialization.

The vulnerability occurs because:

• User-controlled input was allowed to pass through toJSON() without escaping reserved keys.
• The presence of an lc key caused LangChain’s deserializer to assume the object was internally generated.
• No validation existed to distinguish real framework objects from attacker-crafted lookalikes.

As a result, attacker-supplied JSON could masquerade as legitimate LangChain components.

Affected Versions

The following versions are vulnerable:

• @langchain/core versions earlier than 0.3.80
• @langchain/core versions earlier than 1.1.8
• langchain versions earlier than 0.3.37
• langchain versions earlier than 1.2.3

The issue has been fixed in:

• @langchain/core 0.3.80 and later
• @langchain/core 1.1.8 and later
• langchain 0.3.37 and later
• langchain 1.2.3 and later

Exploitation Details

An attacker can exploit this vulnerability by sending crafted JSON data to any LangChain-powered application that accepts or processes user input and later serializes or deserializes it.

Common entry points include:

• Chatbot message payloads
• API request bodies
• Webhooks
• Tool inputs
• Memory or state persistence mechanisms

If the application serializes user input and later deserializes it, the injected object may be reconstructed as a valid LangChain object instead of remaining inert data.

Example Exploit Payload

{
  "message": {
    "lc": 1,
    "type": "constructor",
    "id": ["langchain", "RunnableSequence"],
    "kwargs": {
      "steps": []
    }
  }
}

This payload abuses LangChain’s internal object format. When deserialized by a vulnerable version, it may be interpreted as a real RunnableSequence rather than plain user data.

Impact

Successful exploitation can lead to:

• Manipulation of LangChain execution logic
• Injection of unintended runnables or chains
• Corruption of agent workflows
• Unauthorized execution paths
• Integrity violations within LLM pipelines
• Potential escalation into more severe attacks depending on how deserialized objects are used

While this vulnerability alone does not guarantee remote code execution, it significantly weakens application security and may serve as a building block for chained attacks.

MITRE ATT&CK Mapping

• T1190 – Exploit Public-Facing Application
  The vulnerability can be triggered through exposed APIs or services.
• T1609 – Container or Object Injection
  Attacker injects crafted objects into the application’s internal processing.
• T1036 – Masquerading
  Malicious objects impersonate trusted internal LangChain objects.
• T1059 – Command and Scripting Interpreter
  Applicable in scenarios where deserialized objects influence execution logic.

Detection Guidance

There is no automatic alert generated by LangChain itself, so detection must rely on application-level monitoring.

Indicators of suspicious activity include:

• Incoming JSON containing lc keys from untrusted sources
• Unexpected reconstruction of LangChain objects
• Errors or warnings during deserialization
• Abnormal chain or agent behavior without code changes

Example Detection Logic

Conceptual detection rule:

IF incoming_request_body contains "lc"
AND incoming_request_body contains "kwargs"
AND source is external or unauthenticated
THEN flag as potential LangChain serialization injection attempt

Recommended Log Sources

• API gateway and reverse proxy logs
• Application request and response logs
• LangChain debug or trace logs
• Input validation or schema validation errors
• Persistence or memory storage logs

Proof of Concept Status

• No official proof-of-concept has been publicly released.
• The vulnerability is simple to reproduce using crafted JSON payloads.
• Organizations should assume exploit attempts are feasible and practical.

Remediation and Mitigation

The primary and most effective mitigation is to upgrade to a patched version.

Official Patch (Upgrade Required):
https://github.com/langchain-ai/langchainjs/releases

Additional defensive measures include:

• Strict validation of all user-provided JSON
• Explicitly blocking or stripping reserved keys such as lc, id, and kwargs
• Enforcing schema validation on API inputs
• Avoiding deserialization of untrusted data into executable components
• Enabling detailed logging around serialization and deserialization paths

Final Assessment

CVE-2025-68665 is a high-severity trust-boundary vulnerability rooted in unsafe serialization handling. Any LangChain JS application that processes external input and relies on object serialization is at risk if running a vulnerable version.

Immediate patching is strongly recommended, along with input validation and monitoring controls, to prevent abuse of this flaw in production environments.