LangChain deserialization flaw exposes secrets through prompt injection

At a glance

What this is: This is a critical LangChain deserialization vulnerability that can turn manipulated LLM output into secret exposure and unintended internal actions.

Why it matters: It matters because teams using LLM-driven workflows must govern output handling, object trust, and secret exposure across AI, NHI, and broader application identity controls.

By the numbers:

• CVE-2025-68664 carries a CVSS score of 9.3.

👉 Read Orca Security's analysis of the LangChain deserialization vulnerability

Context

LangChain deserialization becomes a security boundary when attacker-controlled model output can be treated as trusted data. In this case, the risk is not only prompt injection, but the way serialization logic can let special dictionary keys alter how objects are reconstructed, which is exactly where LLM workflows begin to overlap with identity and secret governance.

For practitioners, the central issue is that AI-driven applications often move secrets, metadata, and runtime objects through the same execution path. Once output fields can be influenced externally, the trust model shifts from ordinary application parsing to a control problem spanning AI workflow design, NHI secret exposure, and authorization for internal actions.

Key questions

Q: What breaks when AI output is allowed to drive object deserialization?

A: The trust boundary breaks. Once untrusted model output can determine which object is reconstructed, attackers can move from text manipulation to secret exposure, class instantiation, and side effects. That turns prompt injection into a runtime compromise path. Teams should treat every output-to-object bridge as a high-risk control point, especially where secrets or backend actions are reachable.

Q: Why does prompt injection become more serious when serialization is involved?

A: Prompt injection is more serious when serialization is involved because the attack payload can stop being content and start becoming structure. If attacker-controlled output reaches a deserializer, reserved keys and crafted fields may influence object creation, secret access, or internal logic execution. The risk is not the prompt alone, but the downstream trust placed on the model’s output.

Q: How can security teams reduce secret exposure in LLM-driven workflows?

A: Security teams should remove secret access from any code path that accepts model output, enforce strict schema validation, and keep environment variables out of deserialization pathways. If a workflow must handle AI-generated content, it should do so as data only, with no ability to instantiate objects, call internal services, or reach sensitive credentials.

Q: Who is accountable when a vulnerable AI workflow exposes API keys?

A: Accountability sits with the teams that approved the trust boundary, not just the developers who used the framework. Security, platform, and application owners all have a role when model output can reach secrets or execution logic. The correct control view is shared governance over AI runtime paths, because the failure spans code, identity, and secrets management.

Technical breakdown

How LangChain deserialization turns untrusted output into trusted objects

LangChain Core’s serialization logic reconstructs objects from structured data. In a safe design, user-controlled fields are treated as data only, with reserved keys ignored or escaped. CVE-2025-68664 arises because special handling of the reserved `lc` key can cause the deserializer to interpret attacker-shaped input as a trusted object instead of inert content. That matters because deserialization is not passive parsing. It can determine which classes are instantiated, which fields are populated, and whether side effects are triggered during object creation. Once that boundary fails, a model output field becomes a payload carrier for higher-risk behaviour inside the application runtime.

Practical implication: treat deserialization of model output as an attack surface and remove any path that converts untrusted LLM output directly into executable objects.

Prompt injection as a delivery mechanism for serialization abuse

Prompt injection matters here because the attacker does not need direct authenticated access if they can influence model output. The vulnerable path begins when an LLM response, metadata field, or similar output channel contains attacker-shaped dictionary data. If the application then deserializes that structure, the attack payload is no longer just text. It can carry reserved keys, reference internal classes, and steer the application toward secret retrieval or unintended logic execution. This is why AI workflow security cannot stop at prompt filtering. Output handling, object reconstruction, and runtime permissions are part of the same control plane when model responses are fed back into application logic.

Practical implication: separate untrusted model output from any code path that can influence object instantiation, secret access, or internal service calls.

Environment variable exposure and side effects are the real business risk

The practical impact is broader than a single secret leak. If the deserializer can instantiate internal classes, it may trigger side effects such as network calls or file operations, which creates a path from prompt injection to application compromise. Environment variables are especially exposed because they commonly hold API keys, tokens, and backend credentials. In NHI terms, the issue is a secret handling failure combined with unsafe trust in runtime data. The control failure is not merely missing validation. It is allowing a data serialization path to cross from parsing into execution with access to sensitive non-human credentials.

Practical implication: inventory every workflow that stores secrets in environment variables and ensure those values cannot be reached through model-driven object reconstruction.

Threat narrative

Attacker objective: The attacker aims to convert manipulated AI output into secret disclosure and execution paths that can be used for broader compromise.

1. Entry begins when an attacker influences an LLM output field or response metadata that the application later feeds into LangChain deserialization.
2. Credential access occurs when the crafted `lc` dictionary causes trusted-object reconstruction and exposes environment variables containing API keys or other secrets.
3. Escalation follows if the deserializer instantiates internal classes with side effects, allowing unexpected network calls, file operations, or deeper application compromise.
4. Impact is secret theft and unauthorized internal logic execution, with potential pivot into backend systems that rely on the exposed credentials.

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

Untrusted LLM output should never be allowed to determine object identity. This flaw shows what happens when serialization logic treats model-generated structures as trustworthy reconstruction material. The issue is not just prompt injection. It is a broken trust boundary between text generation and executable runtime state, which is exactly where AI workflow security becomes an identity problem. Practitioners should treat object reconstruction from AI output as a governance failure, not a parsing detail.

Prompt injection becomes materially more dangerous when it reaches deserialization, not just prompting. Many teams focus on content filtering, but this issue demonstrates that the higher-risk boundary is where structured output is converted into internal objects. That is where secret access, class instantiation, and side effects converge. The implication for practitioners is that AI security controls must extend beyond prompt hygiene into runtime handling of outputs and downstream object creation.

Secret-bearing environment variables create a fragile NHI trust zone inside AI workflows. The vulnerability matters because secrets are often colocated with runtime logic in ways that assume deserialization is safe. That assumption fails when attacker-controlled output can trigger object creation and secret reads in the same execution path. The implication is that secret exposure risk must be assessed in the context of model-mediated execution, not only in the vault or secrets manager.

AI workflow serialization is now part of the non-human identity attack surface. This is not a traditional authN/authZ issue, but it is a control boundary for how machine identities, secrets, and runtime actions intersect. When internal classes can be instantiated from model output, the application is effectively granting the model indirect influence over NHI-bearing execution paths. Practitioners should reassess which AI workflows can touch secrets, invoke internal classes, or cross trust boundaries after parsing.

Runtime trust should be measured by what a model output can cause, not by whether the input was authenticated. This flaw is exploitable without authentication if an attacker can influence output data, which makes the usual perimeter assumptions inadequate. The relevant question is whether the system ever lets generated content become executable structure. For practitioners, that means reviewing every output-to-object pathway as a potential control failure, not a code hygiene issue.

From our research:

• 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems (39%), inappropriately sharing sensitive data (31%), and revealing access credentials (23%), according to AI Agents: The New Attack Surface report.
• Only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation.
• For a broader breach lens, see The 52 NHI breaches Report for recurring patterns in secret exposure and access abuse.

What this signals

Model output is becoming an execution surface, not just a language surface. As AI systems are wired into internal applications, the boundary between generation and action narrows. Teams should assume that any workflow allowing generated output to influence parsing, object creation, or service calls is now a governance concern, not merely an application bug. That shift means AI output handling belongs in the same review cycle as NHI secret access and privileged service paths.

Secret containment needs to move closer to runtime decision points. If environment variables or tokens are reachable from a model-mediated path, the blast radius is already too broad. Practitioners should review whether internal AI workflows can touch credentials at all, and if so, whether those credentials are isolated enough to survive prompt injection or malicious structured output. The control question is access containment, not just patch cadence.

For practitioners

• Eliminate direct deserialization of model output Keep LLM responses as inert strings or strictly validated schemas. Do not pass response metadata or other model-controlled fields into object reconstruction functions that can instantiate internal classes or trigger side effects.
• Separate secret-bearing runtime paths from AI outputs Review where environment variables, API keys, and tokens are accessible to workflows that consume model output. Remove secret access from any code path that can be influenced by prompt injection or structured response manipulation.
• Patch vulnerable LangChain components immediately Upgrade LangChain to 1.2.5 and LangChain Core to 0.3.81, then verify that all applications and dependent services stop using the vulnerable serialization logic in internet-facing or data-critical deployments.
• Map every output-to-execution bridge Inventory workflows where AI output can influence file operations, network calls, or internal class instantiation. Prioritize the bridges that can reach secrets or backend systems over low-impact prototype paths.

Key takeaways

• This LangChain flaw turns manipulated LLM output into a direct path to secret exposure and unintended execution.
• The disclosed severity is high enough that teams should treat output deserialization as an immediate security boundary, not a low-level implementation detail.
• Patching is necessary, but the deeper fix is removing any AI output path that can influence object reconstruction, secret access, or side-effectful runtime logic.

Key terms

• Prompt Injection: Prompt injection is a technique that manipulates a model’s instructions or outputs so it behaves in ways the operator did not intend. In practice, it becomes dangerous when the model’s generated content is allowed to influence downstream parsing, access decisions, or runtime actions.
• Deserialization: Deserialization is the process of turning structured data back into an object the application can use. It is safe only when the data is fully trusted and tightly constrained. When untrusted input controls object reconstruction, deserialization can become an execution and secret exposure risk.
• Output-to-Execution Bridge: An output-to-execution bridge is any application path where generated content can influence parsing, object creation, or side-effectful logic. In AI workflows, this is a high-risk boundary because it lets untrusted model output cross from text into action, often without obvious authentication or approval gates.
• Runtime Trust Boundary: A runtime trust boundary is the point where data stops being treated as inert and starts affecting execution, authorization, or secret access. For AI systems, the boundary is often crossed when model output is reused by application code, making validation and separation controls essential.

Deepen your knowledge

AI workflow trust boundaries and secret exposure are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are designing controls for model-driven applications with sensitive runtime access, it is worth exploring.

This post draws on content published by Orca Security: LangChain deserialization flaw exposing secrets through prompt injection. Read the original.