All I Want for Christmas Is Your Secrets: LangGrinch hits LangChain Core (CVE-2025-68664) - Cyata | The Control Plane for Agentic Identity

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. The advisory lists 12 distinct vulnerable flows , which are extremely common use cases, such as standard event streaming, logging, message history/memory or caches: The most damaging outcomes include: Secret extraction from environment variables. The advisory notes this happens when deserialization is performed with secrets_from_env=True. Notably, this was the default until yesterday . 🙂 Object instantiation within pre-approved namespaces (including langchain_core , langchain_openai, langchain_aws, langchain_anthropic... ), potentially triggering side effects in constructors (network calls, file operations, etc.). Under certain conditions LangChain object instantiation may lead to arbitrary code execution. This is categorized under CWE-502: Deserialization of Untrusted Data , with a CNA CVSS score of 9.3 (Critical) . My research story: how I stumbled into it ’Twas the night before Christmas, and I was doing the least festive kind of work: staring at serialization code and asking “wait... why is that trusted?”...

Preview: ~500 words