LangChain Core deserialization flaw exposes AI app secret risk

At a glance

What this is: This is an analysis of CVE-2025-68664 in LangChain Core, a deserialization flaw that can turn ordinary AI app data flows into code execution and secret-exposure paths.

Why it matters: It matters because AI application frameworks now sit inside identity and secrets workflows, so IAM, NHI, and platform teams need to treat serialization paths as part of the trust boundary.

👉 Read ZioSec's analysis of CVE-2025-68664 in LangChain Core

Context

CVE-2025-68664 is a serialization and deserialization flaw in LangChain Core, the framework many teams use to build LLM-enabled applications. The security problem is not limited to one function call. It sits in the boundary between user-controlled data, object reconstruction, and the secrets and runtime context those objects can reach.

For identity and access teams, the important point is that AI application stacks increasingly touch credentials, tokens, environment variables, cached state, and event logs. Once those data paths can be influenced by attacker-controlled input, the framework starts behaving like an identity-adjacent trust broker rather than a neutral library. That makes serialization hygiene a governance issue, not just a code fix.

Key questions

Q: What breaks when AI frameworks deserialize untrusted application data?

A: The trust boundary breaks. If untrusted data can influence object reconstruction, the framework may instantiate objects with side effects, expose secrets, or trigger code paths the developer never intended. In AI applications, that turns ordinary message handling, logging, or caching into an execution path. Security teams should treat deserialization as a privileged operation, not a neutral data conversion step.

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. If deserialization or object instantiation can reach those values, secret governance is no longer isolated inside vault tooling. IAM and platform teams need to understand which libraries can surface secrets during normal application execution.

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. Then verify that logs, caches, and message histories cannot replay hostile payloads into the same code path. If those controls are missing, the application still has a live deserialization attack surface.

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.

Technical breakdown

How unsafe deserialization turns data into executable objects

Serialization converts objects into a storable format, while deserialization rebuilds them later. In LangChain Core, the vulnerable path involves dictionaries carrying a reserved lc marker. If user-controlled content reaches dumps() or dumpd() without proper escaping, the framework may reconstruct objects from attacker-shaped data. That matters because object creation is not passive. In Python ecosystems, instantiation can trigger methods, side effects, and access to environment-backed secrets. The problem is therefore not just malformed input. It is that the application treats untrusted data as if it were trusted object state.

Practical implication: teams should review every path where untrusted data is serialised and later reconstructed, especially where reserved keys or object metadata are involved.

Why event streaming, logs, and caches widen the attack surface

LangChain applications commonly move data through additional_kwargs, response_metadata, message history, caches, and telemetry. These are normal operational paths, which is why they are dangerous when deserialization is unsafe. If attacker-controlled content is written into one of these stores and later read back, the malicious payload can survive beyond the original request and execute when the application processes it again. That shifts the attack from a single input validation bug to a persistence mechanism inside the application layer. Logging and caching systems become replay surfaces for hostile object graphs.

Practical implication: teams need to treat logs, cached state, and message history as untrusted input sinks, not safe internal storage.

How secrets_from_env and object instantiation create credential exposure risk

The advisory notes that secrets_from_env=True was the default before remediation, which is a classic example of a convenience setting becoming a secret-exposure amplifier. If deserialization can influence which objects are instantiated, and those objects can read environment variables, then the application boundary no longer protects credentials in process memory. This is not a traditional IAM failure. It is a runtime trust failure in a framework that bridges application data and secret access. For NHI governance, the key issue is that secrets are only as safe as the code path that can reach them.

Practical implication: teams should audit any framework default that allows runtime access to environment secrets during object reconstruction or helper execution.

Threat narrative

Attacker objective: The attacker aims to convert routine AI application data processing into secret disclosure or code execution inside the target environment.

1. Entry occurs when an attacker injects crafted content into serialised fields such as additional_kwargs, response_metadata, message history, or cached application state.
2. Credential access or abuse follows when deserialization reconstructs unsafe objects that can reach environment variables, including secrets_from_env-backed data.
3. Impact occurs when the object instantiation path enables arbitrary code execution, secret extraction, or hostile side effects inside the AI application runtime.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• AI LLM hijack breach — attackers used stolen AWS access keys to hijack Anthropic LLM models on Bedrock.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

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.

Identity-adjacent secrets access is now part of AI framework risk. When a framework can reach environment variables during deserialization, it becomes a bridge between application logic and NHI-style secret handling. That means secrets governance can no longer stop at vaults and token stores. The exposure path includes any framework default that can surface credentials during object creation, which is why platform teams and IAM teams now share responsibility for the same control plane.

Serialization misuse turns observability into persistence. Event streams, logs, caches, and message histories are often treated as low-risk plumbing, but this flaw shows they can preserve hostile payloads long enough to survive normal review cycles. That changes the security model for AI applications: telemetry is no longer only evidence, it can also be an execution carrier. Practitioners should treat these stores as governed trust boundaries, not passive records.

LangChain-style framework risk is a governance problem, not just a patch problem. The vulnerable pattern demonstrates how AI application stacks inherit the same lifecycle and access problems that already exist in NHI governance, but with more dynamic execution paths. The practical conclusion is that framework defaults, secret reachability, and data reconstruction rules all belong inside identity and runtime governance reviews, not only application security testing.

Runtime object reconstruction creates an implicit privilege path. In secure design, least privilege assumes the code path is predictable enough to bound. Here, the object graph itself becomes a way to request capabilities at runtime through deserialization side effects. That means practitioners need to stop assuming that application inputs are separable from access behavior. The implication is that privilege analysis must include library behavior, not just explicit API calls.

From our research:

• 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.
• For the wider control picture, 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, which is why delegated access governance remains a board-level issue.

What this signals

Serialization risk is now an identity governance signal, not just an application bug. AI frameworks are starting to sit on the same trust boundary as secrets stores, workload identities, and delegated access paths. When that happens, the security programme has to review library defaults, runtime reconstruction, and secret reachability together, not as separate workstreams.

The practical shift for practitioners is to extend governance review to any AI application path that can turn data into object state. That includes logs, caches, event streams, and message histories. In NHI terms, those are no longer passive records because they can carry execution context and persistence across requests.

As AI platforms proliferate, the better control question is not whether a framework is popular. It is whether the framework can safely handle untrusted state without giving that state a route to credentials or code execution. Teams that cannot answer that question should assume the trust model is already too loose.

For practitioners

• 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. Confirm that build pipelines, container images, and serverless packages are all rebuilt from the patched baseline.
• 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. Treat each of those paths as an untrusted input boundary and document whether attacker-controlled fields can reach them.
• 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. Replace that pattern with explicit, narrowly scoped secret retrieval outside object creation paths.
• Add detections for unexpected instantiation behavior Alert on unusual network calls, file operations, subprocess activity, or access to protected environment data that occurs immediately after deserialization. Correlate those signals with AI application logs so security teams can distinguish normal model traffic from exploit activity.

Key takeaways

• CVE-2025-68664 shows that unsafe deserialization in AI frameworks can turn routine application data into executable runtime state.
• The exposure matters because logs, caches, and message histories can replay hostile payloads and reach secrets during normal application flows.
• Practitioners should treat serialization boundaries, secret reachability, and object reconstruction defaults as governed control points, not implementation details.

Key terms

• Deserialization: Deserialization is the process of rebuilding an object from stored or transmitted data. In AI application stacks, it becomes risky when the input is not fully trusted and the reconstructed object can trigger side effects, access secrets, or influence runtime behaviour beyond simple data loading.
• Serialized state: Serialized state is application data saved in a format that can later be reconstructed into objects. In AI systems it often appears in logs, caches, message histories, and event streams, which means a weakness in reconstruction logic can turn ordinary stored data into an execution path.
• Runtime trust boundary: A runtime trust boundary is the point where untrusted input should stop and privileged application behaviour should begin. For AI and identity teams, it defines which data can reach secrets, object constructors, and operational side effects without passing through explicit validation and control.

Deepen your knowledge

Serialization boundaries, secret reachability, and runtime trust are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are extending identity governance into AI application stacks, it is worth exploring.

This post draws on content published by ZioSec: Critical CVE-2025-68664 Vulnerability in LangChain Core. Read the original.