TL;DR: A critical LangChain deserialization flaw, CVE-2025-68664, can expose environment secrets and trigger unintended internal actions when attacker-controlled LLM output reaches vulnerable serialization paths, according to Orca Security. The issue shows that prompt injection can become a data theft and code execution problem when AI workflow outputs are treated as trusted objects.
NHIMG editorial — based on content published by Orca Security: LangChain deserialization flaw exposing secrets through prompt injection
By the numbers:
- CVE-2025-68664 carries a CVSS score of 9.3.
Questions worth separating out
Q: What breaks when AI output is allowed to drive object deserialization?
A: The trust boundary breaks.
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.
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.
Practitioner guidance
- Eliminate direct deserialization of model output Keep LLM responses as inert strings or strictly validated schemas.
- Separate secret-bearing runtime paths from AI outputs Review where environment variables, API keys, and tokens are accessible to workflows that consume model output.
- 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.
What's in the full article
Orca Security's full article covers the operational detail this post intentionally leaves for the source:
- Version-specific patch guidance for LangChain Core and LangChain deployments affected by CVE-2025-68664
- The exact deserialization path and reserved-key handling that enables the `lc` object confusion issue
- Examples of impacted applications that accept LLM output metadata and feed it into structured parsing logic
- Exposure prioritization based on runtime reachability, internet accessibility, and asset criticality
👉 Read Orca Security's analysis of the LangChain deserialization vulnerability →
LangChain CVE-2025-68664: what does it mean for AI workflows?
Explore further
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: LangChain deserialization flaw exposes secrets through prompt injection