Vulnerabilities in pkg:npm/langchain

PACKAGE
Advisory Identifier: GHSA-r399-636x-v7f6
Advisory Summary

CVE-2025-68665 is a HIGH (CVSS 8.6) langchain serialization injection vulnerability enables vulnerability (CWE-502: Deserialization of Untrusted Data) affecting @langchain/core libraries in the npm ecosystem. The issue involves langchain serialization injection vulnerability enables secret extraction. Remediation is available by upgrading affected packages to version 1.1.8, 0.3.80, 0.3.37, 1.2.3.

2 Known Advisory Record(s)
Package Vulnerability Intelligence

pkg:npm/langchain

2 Known Advisory Record(s)

Vulnerability advisories affecting package pkg:npm/langchain. Select an advisory below to view technical details or fixes.

Advisory ID CVE / NVD Severity Summary
GHSA-r399-636x-v7f6 CVE-2025-68665 HIGH LangChain serialization injection vulnerability enables secret extraction
GHSA-hc5w-c9f8-9cc4 CVE-2024-7774 MODERATE Langchain Path Traversal vulnerability

CVE-2025-68665 at a Glance

CVE Identifier CVE-2025-68665
GHSA Identifier GHSA-r399-636x-v7f6
Severity HIGH
CVSS v3.1 Base Score 8.6
CWE Classification CWE-502: Deserialization of Untrusted Data
Affected Product @langchain/core
Package Ecosystem npm
Published Date
Last Updated

Security Impact

CVSS: 8.6

The security impact metrics below are parsed directly from the CVSS v3.1 vector string (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:N/A:N).

Attack Vector Network (AV:N)
Attack Complexity Low (AC:L)
Privileges Required None (PR:N)
User Interaction None (UI:N)
Scope Changed (S:C)
Confidentiality High (C:H)
Integrity None (I:N)
Availability None (A:N)

How to Fix CVE-2025-68665

To remediate this vulnerability, upgrade all affected @langchain/core dependencies to a patched release. Both direct and transitive dependencies should be checked, as frameworks or security libraries may pull in vulnerable versions transitively.

@langchain/core fixed: 1.1.8
npm install @langchain/core@1.1.8
@langchain/core fixed: 0.3.80
npm install @langchain/core@0.3.80
langchain fixed: 0.3.37
npm install langchain@0.3.37
langchain fixed: 1.2.3
npm install langchain@1.2.3
Verify Direct and Transitive Dependencies

Run the following command in your project directory to verify that all resolved dependencies use the patched release:

npm ls @langchain/core

How to Check if You Are Affected

To determine whether your Node.js application is affected by CVE-2025-68665, inspect your project dependencies using npm:

npm ls @langchain/core

Analyze the terminal output to locate any version of @langchain/core in your dependency tree. If any resolved version matches the vulnerable ranges listed in the table below (for example, versions earlier than 1.1.8), your application is affected.

Note: The npm ls @langchain/core command inspects dependencies declared in your package.json and lockfile; it does not perform automated runtime dynamic scanning.

Technical Details

Vulnerability Mechanism & Technical Analysis

This vulnerability is classified under CWE-502: Deserialization of Untrusted Data, where the product deserializes untrusted data without sufficiently ensuring that the resulting data will be valid. In @langchain/core, software state validation or input boundaries are circumvented during processing. Review the official source advisory statement below for specific affected components, classes, and reproduction details.

Source Advisory Statement

## 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: 1. **Injection via user data**: Malicious LangChain object structures could be injected through user-controlled fields like `metadata`, `additional_kwargs`, or `response_metadata` 2. **Secret extraction**: Injected secret structures could extract environment variables when `secretsFromEnv` was enabled (which had no explicit default, effectively defaulting to `true` behavior) 3. **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: 1. **Serialize untrusted data via `JSON.stringify()` on Serializable objects, then deserialize with `load()`** — 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. 2. **Deserialize untrusted data with `load()`** — Directly deserializing untrusted data that may contain injected `'lc'` structures. 3. **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_kwargs` can be controlled via prompt injection ## Exploit example ```typescript 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()`: 1. **`secretsFromEnv` default changed to `false`**: Disables automatic secret loading from environment variables. Secrets not found in `secretsMap` now throw an error instead of being loaded from `process.env`. This fail-safe behavior ensures missing secrets are caught immediately rather than silently continuing with `null`. 2. **New `maxDepth` parameter** (defaults to `50`): Protects against denial-of-service attacks via deeply nested JSON structures that could cause stack overflow. 3. **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. 4. **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: ```typescript 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: ```typescript 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 `secretsFromEnv` if you trust the serialized data. Untrusted data could extract any environment variable. > **Note:** If a secret reference is encountered but not found in `secretsMap` (and `secretsFromEnv` is `false` or 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 receiving `null` values. ### For deeply nested structures If you have legitimate deeply nested data that exceeds the default depth limit of 50: ```typescript 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: ```typescript 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! }); ```

CVE-2025-68665 Affected @langchain/core Versions

4 component(s)
Fixed Versions:
1.1.80.3.800.3.371.2.3
Product / Package Ecosystem Affected Versions Fixed Version
@langchain/core
npm
≥ 1.0.0
< 1.1.8
1.1.8
@langchain/core
npm
< 0.3.80
0.3.80
langchain
npm
< 0.3.37
0.3.37
langchain
npm
≥ 1.0.0
< 1.2.3
1.2.3

References

Frequently Asked Questions

What is CVE-2025-68665?
CVE-2025-68665 is a security vulnerability in @langchain/core involving LangChain serialization injection vulnerability enables secret extraction under CWE-502: Deserialization of Untrusted Data.
Which @langchain/core versions are affected?
Affected versions include releases prior to 1.1.8, 0.3.80, 0.3.37, 1.2.3 across affected packages: @langchain/core, langchain.
What version fixes CVE-2025-68665?
Upgrading to 1.1.8, 0.3.80, 0.3.37, 1.2.3 (or the latest patched release for your respective branch) resolves the vulnerability.
Is @langchain/core affected?
Yes, @langchain/core is affected in releases prior to 1.1.8, 0.3.80. Upgrade your dependency to 1.1.8, 0.3.80 or later.
Is langchain affected?
Yes, langchain is affected in releases prior to 0.3.37, 1.2.3. Upgrade your dependency to 0.3.37, 1.2.3 or later.
What is the CVSS score of CVE-2025-68665?
CVE-2025-68665 has a CVSS v3.1 base score of 8.6 (HIGH) with vector string CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:N/A:N.
What CWE is associated with CVE-2025-68665?
CVE-2025-68665 is classified under CWE-502: Deserialization of Untrusted Data (The product deserializes untrusted data without sufficiently ensuring that the resulting data will be valid.).
How can I check npm dependencies for CVE-2025-68665?
Run the dependency tree command: 'npm ls @langchain/core'. This command lists direct and transitive dependencies in your build configuration so you can verify if a vulnerable version is resolved.
Machine-readable OSV JSON OSV v1.5 Schema
Normalized schema output
{
  "schema_version" : "1.4.0",
  "id" : "GHSA-r399-636x-v7f6",
  "modified" : "2025-12-24T01:08:11Z",
  "published" : "2025-12-23T20:08:48Z",
  "aliases" : [ "CVE-2025-68665" ],
  "summary" : "LangChain serialization injection vulnerability enables secret extraction",
  "details" : "## Context\n\nA 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.\n\n### Attack surface\n\nThe 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.\n\nThis escaping bug enabled several attack vectors:\n\n1. **Injection via user data**: Malicious LangChain object structures could be injected through user-controlled fields like `metadata`, `additional_kwargs`, or `response_metadata`\n2. **Secret extraction**: Injected secret structures could extract environment variables when `secretsFromEnv` was enabled (which had no explicit default, effectively defaulting to `true` behavior)\n3. **Class instantiation via import maps**: Injected constructor structures could instantiate any class available in the provided import maps with attacker-controlled parameters\n\n**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.\n\n**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.\n\n## Who is affected?\n\nApplications are vulnerable if they:\n\n1. **Serialize untrusted data via `JSON.stringify()` on Serializable objects, then deserialize with `load()`** — 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.\n2. **Deserialize untrusted data with `load()`** — Directly deserializing untrusted data that may contain injected `'lc'` structures.\n3. **Use LangGraph checkpoints** — Checkpoint serialization/deserialization paths may be affected.\n\nThe 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.\n\n## Impact\n\nAttackers 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.\n\nKey severity factors:\n\n- Affects the serialization path—applications trusting their own serialization output are vulnerable\n- Enables secret extraction when combined with `secretsFromEnv: true`\n- LLM responses in `additional_kwargs` can be controlled via prompt injection\n\n## Exploit example\n\n```typescript\nimport { load } from \"@langchain/core/load\";\n\n// Attacker injects secret structure into user-controlled data\nconst attackerPayload = JSON.stringify({\n  user_data: {\n    lc: 1,\n    type: \"secret\",\n    id: [\"OPENAI_API_KEY\"],\n  },\n});\n\nprocess.env.OPENAI_API_KEY = \"sk-secret-key-12345\";\n\n// With secretsFromEnv: true, the secret is extracted\nconst deserialized = await load(attackerPayload, { secretsFromEnv: true });\n\nconsole.log(deserialized.user_data); // \"sk-secret-key-12345\" - SECRET LEAKED!\n```\n\n## Security hardening changes\n\nThis patch introduces the following changes to `load()`:\n\n1. **`secretsFromEnv` default changed to `false`**: Disables automatic secret loading from environment variables. Secrets not found in `secretsMap` now throw an error instead of being loaded from `process.env`. This fail-safe behavior ensures missing secrets are caught immediately rather than silently continuing with `null`.\n2. **New `maxDepth` parameter** (defaults to `50`): Protects against denial-of-service attacks via deeply nested JSON structures that could cause stack overflow.\n3. **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.\n4. **JSDoc security warnings**: All import map options (`importMap`, `optionalImportsMap`, `optionalImportEntrypoints`) now include security warnings about never populating them from user input.\n\n## Migration guide\n\n### No changes needed for most users\n\nIf you're deserializing standard LangChain types (messages, documents, prompts) using the core import map, your code will work without changes:\n\n```typescript\nimport { load } from \"@langchain/core/load\";\n\n// Works with default settings\nconst obj = await load(serializedData);\n```\n\n### For secrets from environment\n\n`secretsFromEnv` now defaults to `false`, and missing secrets throw an error. If you need to load secrets:\n\n```typescript\nimport { load } from \"@langchain/core/load\";\n\n// Provide secrets explicitly (recommended)\nconst obj = await load(serializedData, {\n  secretsMap: { OPENAI_API_KEY: process.env.OPENAI_API_KEY },\n});\n\n// Or explicitly opt-in to load from env (only use with trusted data)\nconst obj = await load(serializedData, { secretsFromEnv: true });\n```\n\n> **Warning:** Only enable `secretsFromEnv` if you trust the serialized data. Untrusted data could extract any environment variable.\n\n> **Note:** If a secret reference is encountered but not found in `secretsMap` (and `secretsFromEnv` is `false` or 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 receiving `null` values.\n\n### For deeply nested structures\n\nIf you have legitimate deeply nested data that exceeds the default depth limit of 50:\n\n```typescript\nimport { load } from \"@langchain/core/load\";\n\nconst obj = await load(serializedData, { maxDepth: 100 });\n```\n\n### For custom import maps\n\nIf you provide custom import maps, ensure they only contain trusted modules:\n\n```typescript\nimport { load } from \"@langchain/core/load\";\nimport * as myModule from \"./my-trusted-module\";\n\n// GOOD - explicitly include only trusted modules\nconst obj = await load(serializedData, {\n  importMap: { my_module: myModule },\n});\n\n// BAD - never populate from user input\nconst obj = await load(serializedData, {\n  importMap: userProvidedImports, // DANGEROUS!\n});\n```",
  "severity" : [ {
    "type" : "CVSS_V3",
    "score" : "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:N/A:N"
  } ],
  "affected" : [ {
    "package" : {
      "ecosystem" : "npm",
      "name" : "@langchain/core"
    },
    "ranges" : [ {
      "type" : "ECOSYSTEM",
      "events" : [ {
        "introduced" : "1.0.0"
      }, {
        "fixed" : "1.1.8"
      } ]
    } ]
  }, {
    "package" : {
      "ecosystem" : "npm",
      "name" : "@langchain/core"
    },
    "ranges" : [ {
      "type" : "ECOSYSTEM",
      "events" : [ {
        "introduced" : "0"
      }, {
        "fixed" : "0.3.80"
      } ]
    } ]
  }, {
    "package" : {
      "ecosystem" : "npm",
      "name" : "langchain"
    },
    "ranges" : [ {
      "type" : "ECOSYSTEM",
      "events" : [ {
        "introduced" : "1.0.0"
      }, {
        "fixed" : "1.2.3"
      } ]
    } ]
  }, {
    "package" : {
      "ecosystem" : "npm",
      "name" : "langchain"
    },
    "ranges" : [ {
      "type" : "ECOSYSTEM",
      "events" : [ {
        "introduced" : "0"
      }, {
        "fixed" : "0.3.37"
      } ]
    } ]
  } ],
  "references" : [ {
    "type" : "WEB",
    "url" : "https://github.com/langchain-ai/langchainjs/security/advisories/GHSA-r399-636x-v7f6"
  }, {
    "type" : "ADVISORY",
    "url" : "https://nvd.nist.gov/vuln/detail/CVE-2025-68665"
  }, {
    "type" : "WEB",
    "url" : "https://github.com/langchain-ai/langchainjs/commit/e5063f9c6e9989ea067dfdff39262b9e7b6aba62"
  }, {
    "type" : "PACKAGE",
    "url" : "https://github.com/langchain-ai/langchainjs"
  }, {
    "type" : "WEB",
    "url" : "https://github.com/langchain-ai/langchainjs/releases/tag/%40langchain%2Fcore%401.1.8"
  }, {
    "type" : "WEB",
    "url" : "https://github.com/langchain-ai/langchainjs/releases/tag/langchain%401.2.3"
  } ],
  "database_specific" : {
    "cwe_ids" : [ "CWE-502" ],
    "severity" : "HIGH",
    "github_reviewed" : true,
    "github_reviewed_at" : "2025-12-23T20:08:48Z",
    "nvd_published_at" : "2025-12-23T23:15:45Z"
  }
}