CVE-2025-68665: High Serialization Injection in LangChain JS

CVE-2025-68665 is a high severity (CVSS 8.6) serialization injection flaw in LangChain JS. The toJSON() method did not escape objects with lc keys in free form data, so later loading could treat user data as LangChain objects. Upgrade @langchain/core to 0.3.80 or 1.1.8 and langchain to 0.3.37 or 1.2.3.

What's affected

Per the GitHub advisory GHSA-r399-636x-v7f6 and the record, these npm packages are affected.

• @langchain/core: affected below 0.3.80, and from 1.0.0 up to below 1.1.8. Patched in 0.3.80 and 1.1.8.
• langchain: affected below 0.3.37, and from 1.0.0 up to below 1.2.3. Patched in 0.3.37 and 1.2.3.

The record and the advisory agree on severity (High, 8.6, vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:N/A:N) and on versions. They differ on weakness class in one small way: the record lists CWE-502 (deserialization of untrusted data), while the advisory page lists no CWE. This post uses the record's CWE.

The advisory says applications may be affected if they serialize untrusted data with JSON.stringify() and later call load(), deserialize untrusted data directly, or use LangGraph checkpoints. LLM response fields can be influenced through prompt injection, which is why model output counts as untrusted here. The record does not flag this as exploited in the wild (KEV is false).

How to check if you're exposed

List the installed versions in each project:

npm ls @langchain/core langchain

With pnpm or yarn:

pnpm why @langchain/core
yarn why @langchain/core

Compare the result with the ranges above. Transitive installs count, since many packages pull in @langchain/core. Then check whether your code calls load() on data that could contain user or model controlled content, and whether you use LangGraph checkpoints.

What to do now

1. Upgrade @langchain/core and langchain to a patched version on your line, then reinstall and regenerate your lock file.
2. Search your code for load( calls from LangChain and note what data feeds them.
3. Pass secrets explicitly through secretsMap. The fixed releases set secretsFromEnv to false by default and raise an error for missing secrets, and the advisory says to enable it only for trusted data.
4. Never fill importMap, optionalImportsMap or optionalImportEntrypoints from user input.
5. Rebuild and redeploy services that bundle the library, such as containers and serverless packages.

Why it matters

The cause, per the advisory, is that toJSON() did not escape user controlled objects containing lc keys inside fields such as additional_kwargs, metadata and response_metadata. LangChain uses lc to mark its own serialized objects. When load() later read the data back, it could not tell a legitimate object from user data shaped like one.

The advisory describes two consequences. With secretsFromEnv enabled, injected structures could read environment variables. Separately, injected structures could instantiate classes available in the configured import maps with chosen parameters. Environment variables often hold API keys, so the first risk is the one most teams will care about.

The fix escapes lc objects when serializing and treats them as plain data when loading, adds a maxDepth option with a default of 50, and tightens secret handling. This is a good example of why dependency inventory and reachability matter in AI application stacks: the library is often several layers down, and whether load() touches untrusted data decides if you are really exposed.

Try it yourself

Click through it at your own pace, or open it full screen.

Quick check

Sources

• Safeguard Gold entry for CVE-2025-68665
• LangChain JS advisory GHSA-r399-636x-v7f6
• @langchain/core 1.1.8 release
• langchain 1.2.3 release
• Fix commit

Last reviewed: 18 October 2026.