Notifications
Clear all
Topic starter
11/06/2026 12:02 am
TL;DR: CVE-2025-68664 in LangChain Core can let crafted serialized data trigger unsafe object instantiation, secret extraction, and arbitrary code execution through normal event, logging, cache, and prompt-driven flows, according to ZioSec. The issue shows that AI application frameworks can turn data handling paths into identity-adjacent execution paths if serialization boundaries are not tightly controlled.
NHIMG editorial — based on content published by ZioSec: Critical CVE-2025-68664 Vulnerability in LangChain Core
Questions worth separating out
Q: What breaks when AI frameworks deserialize untrusted application data?
A: The trust boundary breaks.
Q: Why do AI application frameworks increase secret exposure risk for IAM teams?
A: They connect application data paths to runtime context, including environment variables, cached state, and helper functions that may read credentials.
Q: How can security teams tell whether serialization risk is actually controlled?
A: Look for evidence that untrusted fields are escaped, reserved keys are rejected, and reconstructed objects are limited to a strict allowlist.
Practitioner guidance
- Patch vulnerable LangChain Core versions immediately Move to a fixed release and inventory every service, notebook, and agent workflow that imports the library directly or through transitive dependencies.
- Map all deserialization entry points Identify every place where additional_kwargs, response_metadata, message history, caches, queues, or logs can be serialized and later reconstructed.
- Disable secret retrieval during object reconstruction Review any configuration that allows runtime access to environment variables or secret material during deserialization, including secrets_from_env-style defaults.
What's in the full article
ZioSec's full article covers the operational detail this post intentionally leaves for the source:
- The exact vulnerable LangChain Core functions and the reserved lc handling that triggers the flaw
- Patch version guidance and the specific default settings that changed after the advisory
- Concrete exploitation vectors across event streaming, caches, and prompt-influenced fields
- Detection indicators for unexpected deserialization behaviour and secret access
👉 Read ZioSec's analysis of CVE-2025-68664 in LangChain Core →
LangChain Core serialization risk: what should security teams do now?
Explore further
12/06/2026 6:33 am
Deserialization boundary trust is the named failure mode here. The application assumed that serialized AI workflow data would remain inert until safely rebuilt, but CVE-2025-68664 shows that assumption fails when attacker-controlled dictionaries can shape object reconstruction. This is not simply insecure parsing. It is a broken trust boundary between application data and executable runtime state, and practitioners should treat that boundary as identity-relevant infrastructure.
A few things that frame the scale:
- 1 in 4 organisations are already investing in dedicated NHI security capabilities, with an additional 60% planning to do so within the next twelve months, according to The State of Non-Human Identity Security.
- Only 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, compared to nearly 1 in 4 for securing human identities.
A question worth separating out:
Q: Who is accountable when AI framework defaults expose credentials during runtime?
A: Accountability usually spans application security, platform engineering, and the identity team that owns secrets policy. The key question is who approved the framework default, who allowed secret reachability in runtime code, and who owns the library upgrade path. Governance should assign a named owner for library-level trust boundaries, not leave them implicit.
👉 Read our full editorial: LangChain Core deserialization flaw exposes AI app secret risk
