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.
At a glance
What this is: This is an analysis of CVE-2025-68664 in LangChain Core, where unsafe serialization and deserialization can turn routine AI application data flows into code execution and secret exposure paths.
Why it matters: It matters because AI application frameworks can move untrusted data through logs, caches, and message histories, so IAM and security teams have to treat serialization as part of the control plane around secrets and execution.
Context
CVE-2025-68664 is a deserialization flaw in LangChain Core, the framework used to build generative AI applications. In plain terms, data that should remain inert can be reconstructed into active objects if the serialization boundary is not enforced.
For identity and access teams, the issue is not limited to application correctness. When serialized content can influence object creation, the boundary between data handling and execution becomes a security boundary that can expose environment secrets and trigger unintended behaviour.
That makes the problem relevant to AI application governance, secret handling, and workload identity controls rather than just secure coding. The article’s starting point is typical of modern AI stacks: normal application pathways become attack paths when trust is placed in user-controlled structure.
Key questions
Q: What breaks when AI frameworks deserialize user-controlled data without strict type controls?
A: The framework stops treating input as inert data and starts treating it as executable structure. That can let crafted payloads instantiate unsafe objects, trigger side effects, or reach secret-bearing code paths through ordinary application flows such as logs, caches, and message histories.
Q: Why does secret extraction become possible when deserialization reaches runtime configuration?
A: Because the payload is no longer limited to shaping data, it can influence code paths that touch environment-backed secrets or other sensitive runtime state. Once deserialization crosses into configuration logic, the attacker may inherit access that was never intended for the original input channel.
Q: What are the signs that an AI application is being abused through serialized payloads?
A: Look for object instantiation that does not match the expected schema, secret lookup activity during rehydration, unusual file operations, and network calls that appear only when specific serialized content is processed. Those signals indicate the deserialization boundary is being exercised as an attack surface.
Q: How should teams reduce the risk of serialization flaws in AI application frameworks?
A: Treat serialization as a security boundary, not a storage format. Constrain object types, separate secret retrieval from untrusted payload handling, and review every path that stores and later replays structured AI application data.
Technical breakdown
Unsafe deserialization in LangChain Core
Serialization converts objects into a storable format, while deserialization rebuilds them. In LangChain Core, the issue described by ZioSec is that user-controlled dictionaries carrying reserved markers such as lc can be processed in ways that instantiate objects the application never meant to create. That matters because object creation is not just parsing. It can execute constructors, load configuration, or trigger side effects. When the deserializer accepts structure from untrusted input, the framework stops treating data as data and starts treating it as instructions.
Practical implication: Treat deserialization as executable trust logic and restrict which object types can be reconstructed from untrusted AI application data.
How event streams, caches, and prompt outputs become exposure paths
The article notes that exploitation can flow through event streaming, logging, message histories, caches, and prompt-driven data. These are ordinary AI application paths, which is why the flaw is dangerous: defenders often assume these channels are passive records. If additional_kwargs or response_metadata are serialized and later deserialized, a malicious payload can survive long enough to reach a dangerous code path without looking like a classic input-validation failure. This is a governance problem as much as a coding problem because multiple application layers may touch the same object boundary.
Practical implication: Audit every place serialized AI application data is stored, replayed, or rehydrated, not just the user-facing input fields.
Secret extraction through environment-backed configuration
ZioSec says secret extraction is possible, especially where secrets_from_env=True was the default before the advisory. That points to a common anti-pattern in AI applications: configuration secrets are assumed to stay outside application-controlled data paths, yet deserialization can bridge that boundary. If object instantiation or related side effects can reach environment-backed secrets, the issue is no longer only about code execution. It also becomes about unauthorized access to credentials, tokens, and other runtime secrets that were never meant to be exposed through application payloads.
Practical implication: Minimise environment-backed secret exposure to deserialised code paths and remove any default setting that allows payload-driven secret access.
Threat narrative
Attacker objective: The attacker aims to turn benign-looking AI application data flows into a path for secret theft and code execution.
- Entry occurs when an attacker places a crafted serialized payload into normal AI application inputs such as event streams, logs, caches, or prompt-influenced fields.
- Credential access or object abuse follows when deserialization processes user-controlled dictionaries containing reserved markers such as lc and reconstruct unsafe objects.
- Escalation happens if object instantiation reaches secrets_from_env=True or other side effects, exposing runtime secrets or enabling arbitrary code execution.
- Impact is secret extraction, application compromise, and potentially broader abuse of the AI workload through the compromised runtime.
Breaches seen in the wild
- LiteLLM MCP auth bypass 2026: An exploited LiteLLM MCP auth bypass and default sk-1234 master keys let attackers steal AI gateway master and provider API keys.
- Gladinet Hard-Coded Keys RCE Exploitation: Actively exploited hard-coded keys in Gladinet CentreStack and Triofox enable remote code execution.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Serialization boundaries are now trust boundaries for AI applications. The LangChain Core flaw shows that AI application frameworks can convert data handling into execution handling when deserialization is not tightly constrained. That breaks the long-standing assumption that logs, caches, and message histories are inert records. Practitioners should treat object rehydration as a governed security control, not a development convenience.
Secret extraction is the governance failure that makes this issue identity-adjacent. The article’s reference to secrets_from_env=True shows how runtime secrets can become reachable through a data path that should never touch them. That is not just a code flaw. It is a control boundary problem where secret stewardship, workload identity, and application runtime design intersect.
Identity-adjacent execution paths need a named control model: rehydration risk. AI frameworks that store and replay structured objects create a rehydration risk surface, where payloads can survive long enough to be turned back into active code paths. The implication for practitioners is clear: control the shape, source, and destination of every object that can be reconstructed from untrusted AI data.
NIST CSF and OWASP-NHI become relevant where AI frameworks act on runtime secrets. This is not a pure application bug in the abstract. It is a governance issue because the framework’s behaviour affects authorisation boundaries, secret exposure, and integrity of execution. Teams need to map these flows to identity and runtime control points rather than leaving them inside generic application review cycles.
Deserialization abuse in AI stacks will keep recurring wherever developers confuse convenience with trust. Any framework that automatically rehydrates structured input without strict type control creates a standing opportunity for secret leakage and unintended execution. The practitioner lesson is to review the full object lifecycle, from ingestion through persistence to replay, before assuming the application boundary is safe.
What this signals
Rehydration risk: AI application stacks that persist and replay structured objects create a control problem that traditional input validation does not solve. The issue is not only what the payload says at ingestion, but what the framework can do when it rebuilds the object later.
For security programmes, this means serialization review has to sit alongside workload identity and secret governance. If a deserialised object can reach environment-backed secrets or trigger side effects, the application boundary has already become a privilege boundary.
For practitioners
- Tighten deserialization allowlists Restrict reconstructed object types to an explicit allowlist and reject user-controlled dictionaries that carry reserved markers or unexpected schema shapes.
- Remove secret access from rehydration paths Disable settings that let deserialised objects reach environment-backed secrets and separate secret retrieval from any code path that accepts untrusted payloads.
- Review replayable AI data stores Inspect event streams, caches, logs, and message histories for serialized objects that can later be rehydrated into active runtime behaviour.
- Add detection for unsafe object instantiation Alert on unexpected object creation, unexplained file access, unusual network calls, or secret lookup activity during deserialization.
Key takeaways
- The core issue is not simply a parsing bug. It is a broken trust boundary between untrusted AI application data and executable runtime objects.
- The article shows that logs, caches, message histories, and prompt-shaped fields can all become delivery paths when serialized content is replayed unsafely.
- The most direct containment is to constrain object reconstruction and remove secret access from any deserialisation path.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10, OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | Unsafe object rehydration can turn AI app data into execution and privilege abuse paths. |
| Recommendation — Constrain agent and framework object rehydration so untrusted payloads cannot influence privileged runtime behaviour. | ||
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | The article explicitly describes secret extraction through deserialisation paths. |
| NHI-04 — Insecure Authentication | The flaw undermines trust in structured inputs that gate access to runtime secrets and code paths. | |
| Recommendation — Eliminate secret exposure from any deserialisation flow and rotate credentials touched by unsafe payloads. Treat deserialised input as untrusted and require explicit authentication checks before any secret-bearing action. | ||
| MITRE ATT&CK | TA0006; TA0004 — Credential Access; Privilege Escalation | The attack path includes secret harvesting and execution through runtime objects. |
| Recommendation — Map unsafe deserialisation to credential access and privilege escalation detections in your threat model. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | AI runtime secrets and object instantiation are authorization boundary issues. |
| Recommendation — Review authorization boundaries so deserialised objects cannot access secrets or privileged runtime functions. | ||
Key terms
- Deserialization: Deserialization is the process of turning stored or transmitted data back into objects a program can use. It becomes dangerous when attacker-crafted input alters object structure or triggers unsafe behaviour, especially when the application assumes the data is already trustworthy.
- Rehydration Risk: The chance that previously stored structured data will be rebuilt into an active object with more power than intended. In AI systems, rehydration risk matters when logs, caches, or message histories can later influence runtime behaviour or secret access.
- Runtime Secret Visibility: Runtime secret visibility is the ability to observe when and where secrets are accessed while systems are actively running. It matters because static inventories alone do not show whether a tool, workflow, or workload is reading credentials in memory, files, or logs.
- Serialization boundary: The serialization boundary is the point where server-rendered data is converted into a form that the browser can receive. In App Router, this boundary is a security control, not just a technical detail, because any sensitive field passed across it may be exposed even when the UI does not render it.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on June 10, 2026.
Updated on October 10, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org