TL;DR: A critical flaw in langchain-core lets attacker-shaped data influence internal serialization and deserialization paths, creating secret-exposure and object-instantiation risk across common streaming, logging, memory, and cache workflows, according to CYATA. The real lesson is that agent frameworks inherit identity-like trust boundaries, so untrusted LLM output cannot be treated as safe structured state.
NHIMG editorial — based on content published by CYATA: Cyata Research on the LangGrinch vulnerability in langchain-core
By the numbers:
- 12 distinct flows in common LangChain use cases., in common LangChain use cases.
Questions worth separating out
Q: What breaks when attacker-shaped LLM output reaches serialization paths in AI frameworks?
A: The failure is trust boundary collapse.
Q: Why do AI agent frameworks create new secrets exposure risks for IAM teams?
A: They combine model output, tool calls, caches, and logging in one runtime path, which means a single unsafe object can cross multiple privilege boundaries.
Q: What do security teams get wrong about allowlists in deserialization?
A: They often assume an allowlisted class is safe because it is approved.
Practitioner guidance
- Inventory every serialization and replay path Map where LLM output, tool output, and retrieved content enter additional_kwargs, response_metadata, message history, caches, and event streams before they are reloaded.
- Disable secret resolution for untrusted serialized input Review any use of secrets_from_env or similar lookup behaviour and require explicit trust boundaries before environment variables can be resolved during deserialization.
- Separate observability data from executable state Prevent logging and tracing pipelines from preserving attacker-shaped fields in a form that later rehydrates into LangChain objects or other privileged structures.
What's in the full article
CYATA's full analysis covers the operational detail this post intentionally leaves for the source:
- The vulnerable code paths in dumps() and dumpd() and how the reserved lc marker is handled in patched versions.
- The full list of 12 affected LangChain flows, including streaming, logging, memory, caches, and hub pulls.
- The constructor side effects in allowlisted classes such as outbound requests and secret resolution.
- The advisory's remediation guidance for production teams running langchain-core and adjacent ecosystem packages.
👉 Read CYATA's analysis of the langchain-core serialization flaw and AI agent trust boundaries →
LangChain core deserialization risk: what IAM and AI teams should know?
Explore further
Marker-based serialization is a hidden identity boundary, not a convenience feature. When a framework uses reserved fields to distinguish trusted objects from ordinary data, it creates an identity decision inside the application runtime. That decision becomes dangerous when attacker-shaped content can present itself as framework-owned structure. The implication is simple: AI platforms must be governed as trust-boundary systems, not just as application code.
A few things that frame the scale:
- 60% of NHIs are being overused, with the same NHI utilised by more than one application, increasing the risk of widespread compromise if exposed, according to The 2025 State of NHIs and Secrets in Cybersecurity.
- 91% of former employee tokens remain active after offboarding, leaving organisations vulnerable to potential security breaches, according to The 2025 State of NHIs and Secrets in Cybersecurity.
A question worth separating out:
Q: How should organisations respond when a core AI framework serialization flaw is disclosed?
A: Patch the core dependency immediately, then trace every place where untrusted model output can be stored and reloaded as structure. Prioritise flows that touch secrets, caches, traces, and message history, because those are the paths most likely to convert a framework bug into real exposure.
👉 Read our full editorial: LangChain core serialization flaw exposes agent framework trust boundaries