CVE-2025-68665
ADVISORY - githubSummary
Context
A serialization injection vulnerability exists in LangChain JS's toJSON() method (and subsequently when string-ifying objects using JSON.stringify(). The method did not escape objects with 'lc' keys when serializing free-form data in kwargs. 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.
Attack surface
The core vulnerability was in Serializable.toJSON(): this method failed to escape user-controlled objects containing 'lc' keys within kwargs (e.g., additional_kwargs, metadata, response_metadata). When this unescaped data was later deserialized via load(), the injected structures were treated as legitimate LangChain objects rather than plain user data.
This escaping bug enabled several attack vectors:
- Injection via user data: Malicious LangChain object structures could be injected through user-controlled fields like
metadata,additional_kwargs, orresponse_metadata - Secret extraction: Injected secret structures could extract environment variables when
secretsFromEnvwas enabled (which had no explicit default, effectively defaulting totruebehavior) - Class instantiation via import maps: Injected constructor structures could instantiate any class available in the provided import maps with attacker-controlled parameters
Note on import maps: Classes must be explicitly included in import maps to be instantiatable. The core import map includes standard types (messages, prompts, documents), and users can extend this via importMap and optionalImportsMap options. This architecture naturally limits the attack surface—an allowedObjects parameter is not necessary because users control which classes are available through the import maps they provide.
Security hardening: This patch fixes the escaping bug in toJSON() and introduces new restrictive defaults in load(): secretsFromEnv now explicitly defaults to false, and a maxDepth parameter protects against DoS via deeply nested structures. JSDoc security warnings have been added to all import map options.
Who is affected?
Applications are vulnerable if they:
- Serialize untrusted data via
JSON.stringify()on Serializable objects, then deserialize withload()— Trusting your own serialization output makes you vulnerable if user-controlled data (e.g., from LLM responses, metadata fields, or user inputs) contains'lc'key structures. - Deserialize untrusted data with
load()— Directly deserializing untrusted data that may contain injected'lc'structures. - Use LangGraph checkpoints — Checkpoint serialization/deserialization paths may be affected.
The most common attack vector is through LLM response fields like additional_kwargs or response_metadata, which can be controlled via prompt injection and then serialized/deserialized in streaming operations.
Impact
Attackers who control serialized data can extract environment variable secrets by injecting {"lc": 1, "type": "secret", "id": ["ENV_VAR"]} to load environment variables during deserialization (when secretsFromEnv: true). They can also instantiate classes with controlled parameters by injecting constructor structures to instantiate any class within the provided import maps with attacker-controlled parameters, potentially triggering side effects such as network calls or file operations.
Key severity factors:
- Affects the serialization path—applications trusting their own serialization output are vulnerable
- Enables secret extraction when combined with
secretsFromEnv: true - LLM responses in
additional_kwargscan be controlled via prompt injection
Exploit example
import { load } from "@langchain/core/load";
// Attacker injects secret structure into user-controlled data
const attackerPayload = JSON.stringify({
user_data: {
lc: 1,
type: "secret",
id: ["OPENAI_API_KEY"],
},
});
process.env.OPENAI_API_KEY = "sk-secret-key-12345";
// With secretsFromEnv: true, the secret is extracted
const deserialized = await load(attackerPayload, { secretsFromEnv: true });
console.log(deserialized.user_data); // "sk-secret-key-12345" - SECRET LEAKED!
Security hardening changes
This patch introduces the following changes to load():
secretsFromEnvdefault changed tofalse: Disables automatic secret loading from environment variables. Secrets not found insecretsMapnow throw an error instead of being loaded fromprocess.env. This fail-safe behavior ensures missing secrets are caught immediately rather than silently continuing withnull.- New
maxDepthparameter (defaults to50): Protects against denial-of-service attacks via deeply nested JSON structures that could cause stack overflow. - Escape mechanism in
toJSON(): User-controlled objects containing'lc'keys are now wrapped in{"__lc_escaped__": {...}}during serialization and unwrapped as plain data during deserialization. - JSDoc security warnings: All import map options (
importMap,optionalImportsMap,optionalImportEntrypoints) now include security warnings about never populating them from user input.
Migration guide
No changes needed for most users
If you're deserializing standard LangChain types (messages, documents, prompts) using the core import map, your code will work without changes:
import { load } from "@langchain/core/load";
// Works with default settings
const obj = await load(serializedData);
For secrets from environment
secretsFromEnv now defaults to false, and missing secrets throw an error. If you need to load secrets:
import { load } from "@langchain/core/load";
// Provide secrets explicitly (recommended)
const obj = await load(serializedData, {
secretsMap: { OPENAI_API_KEY: process.env.OPENAI_API_KEY },
});
// Or explicitly opt-in to load from env (only use with trusted data)
const obj = await load(serializedData, { secretsFromEnv: true });
Warning: Only enable
secretsFromEnvif you trust the serialized data. Untrusted data could extract any environment variable.
Note: If a secret reference is encountered but not found in
secretsMap(andsecretsFromEnvisfalseor the secret is not in the environment), an error is thrown. This fail-safe behavior ensures you're aware of missing secrets rather than silently receivingnullvalues.
For deeply nested structures
If you have legitimate deeply nested data that exceeds the default depth limit of 50:
import { load } from "@langchain/core/load";
const obj = await load(serializedData, { maxDepth: 100 });
For custom import maps
If you provide custom import maps, ensure they only contain trusted modules:
import { load } from "@langchain/core/load";
import * as myModule from "./my-trusted-module";
// GOOD - explicitly include only trusted modules
const obj = await load(serializedData, {
importMap: { my_module: myModule },
});
// BAD - never populate from user input
const obj = await load(serializedData, {
importMap: userProvidedImports, // DANGEROUS!
});
Common Weakness Enumeration (CWE)
Deserialization of Untrusted Data
Deserialization of Untrusted Data
Deserialization of Untrusted Data
GitHub
3.9
CVSS SCORE
8.6high| Package | Type | OS Name | OS Version | Affected Ranges | Fix Versions |
|---|---|---|---|---|---|
| langchain | npm | - | - | <0.3.37 | 0.3.37 |
| @langchain/core | npm | - | - | <0.3.80 | 0.3.80 |
| @langchain/core | npm | - | - | >=1.0.0,<1.1.8 | 1.1.8 |
| langchain | npm | - | - | >=1.0.0,<1.2.3 | 1.2.3 |
CVSS:3 Severity and metrics
The CVSS metrics represent different qualitative aspects of a vulnerability that impact the overall score, as defined by the CVSS Specification.
The vulnerable component is bound to the network stack, but the attack is limited at the protocol level to a logically adjacent topology. This can mean an attack must be launched from the same shared physical (e.g., Bluetooth or IEEE 802.11) or logical (e.g., local IP subnet) network, or from within a secure or otherwise limited administrative domain (e.g., MPLS, secure VPN to an administrative network zone). One example of an Adjacent attack would be an ARP (IPv4) or neighbor discovery (IPv6) flood leading to a denial of service on the local LAN segment (e.g., CVE-2013-6014).
Specialized access conditions or extenuating circumstances do not exist. An attacker can expect repeatable success when attacking the vulnerable component.
The attacker is unauthorized prior to attack, and therefore does not require any access to settings or files of the vulnerable system to carry out an attack.
The vulnerable system can be exploited without interaction from any user.
An exploited vulnerability can affect resources beyond the security scope managed by the security authority of the vulnerable component. In this case, the vulnerable component and the impacted component are different and managed by different security authorities.
There is a total loss of confidentiality, resulting in all resources within the impacted component being divulged to the attacker. Alternatively, access to only some restricted information is obtained, but the disclosed information presents a direct, serious impact. For example, an attacker steals the administrator's password, or private encryption keys of a web server.
There is no loss of trust or accuracy within the impacted component.
There is no impact to availability within the impacted component.
NIST
3.9
CVSS SCORE
8.6highRed Hat
3.9
CVSS SCORE
8.6highChainguard
CGA-2647-cxvh-h433
-
Chainguard
CGA-3j5g-5xmp-j94g
-
Chainguard
CGA-5jm5-f3m6-mhmp
-
Chainguard
CGA-653q-7mqw-vh62
-
Chainguard
CGA-85gf-57xg-6wj7
-
Chainguard
CGA-8p8v-67qm-4w6v
-
Chainguard
CGA-j6g2-j3qm-7xq9
-
Chainguard
CGA-jrj3-4996-4c57
-
Chainguard
CGA-qj7v-w227-m739
-
Chainguard
CGA-ww85-vvcj-gg3g
-
minimos
MINI-2pfh-rpgg-45qm
-
minimos
MINI-8mhc-xcr8-5jf9
-
minimos
MINI-f8p8-cwrc-63p9
-
minimos
MINI-fcwp-2ggg-x29m
-
minimos
MINI-fhgx-3qx6-vwrr
-
minimos
MINI-j67g-8qwp-8v9q
-
minimos
MINI-m8qc-mf4g-qc2m
-
minimos
MINI-w68f-82vf-h2cc
-