Cyata Research: LangGrinch Vulnerability in LangChain
Yesterday, LangChain published a critical advisory for a vulnerability I reported in langchain-core: CVE-2025-68664 / GHSA-c67j-w6g6-q2cm.
Earlier this year, my research focused on breaking secret managers in our “Vault Fault” work – systems that are explicitly designed to be the security boundary around your most sensitive credentials. One takeaway kept repeating: when a platform accidentally treats attacker-shaped data as trusted structure, that boundary collapses fast. This time, the system that “breaks” isn’t your secret manager. It’s the agent framework that may use them.
Why this vulnerability deserves extra attention:
It’s in Core. This is not a specific tool bug, not an integration edge-case, and not a “some community package did something weird.” The vulnerable APIs (dumps() / dumpd()) live in langchain-core itself. The blast radius is scale. By download volume, langchain is one of the most widely deployed AI framework components globally today. As of late December 2025, public package telemetry shows hundreds of millions of installs, with pepy.tech reporting ~847M total downloads and pypistats showing ~98M downloads in the last month. One prompt can trigger a lot of machinery. The most common real-world path here is not “attacker sends you a serialized blob and you call load().” It’s subtler: LLM outputs can influence fields like additional_kwargs or response_metadata, and those fields can be serialized and later deserialized through normal framework features like streaming logs/events. Plainly, this means an exploit can be triggered by a single text prompt that cascades into a surprisingly complex internal pipeline.
Before you read further, patches are now released in versions 1.2.5 and 0.3.81. If you’re running LangChain in production, this one is trickier than it may seem; please update ASAP.
The short version of the bug
LangChain uses a special internal serialization format where dictionaries containing an ‘lc’ marker represent LangChain objects. The vulnerability was that dumps() and dumpd() did not properly escape user-controlled dictionaries that happened to include the reserved ‘lc’ key.
So once an attacker is able to make a LangChain orchestration loop serialize and later deserialize content including an ‘lc’ key, they would instantiate an unsafe arbitrary object, potentially triggering many attacker-friendly paths.
... continue reading