LangChain Core CVE-2025-68664

Exploitation requires the application to serialize untrusted/user-controlled data with LangChain's dumps() or dumpd() and later deserialize it with load() or loads(). Concretely, affected applications are those that: (1) use astream_events(version='v1') - note version='v2' is NOT affected; (2) use Runnable.astream_log(); or (3) directly call dumps()/dumpd() on untrusted input and trust that output for later deserialization. The attacker must be able to place an 'lc'-keyed dictionary into a user-controlled field such as metadata, additional_kwargs, or response_metadata. Limiting factors: instantiation is restricted to pre-approved trusted namespaces (langchain_core, langchain, langchain_community) since namespace validation already existed before the patch, so arbitrary external class loading is NOT possible; applications on langchain-core >=0.3.81/>=1.2.5, or those that never deserialize serialized untrusted data, or that only use astream_events v2, are not exposed.

This is a genuine but conditional risk rather than a drop-everything emergency. The CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:N) scores 8.2 and describes network-reachable, low-complexity, unauthenticated exploitation with high confidentiality impact (C:H) and limited integrity impact (I:L, S:U) - consistent with the GHSA framing that the core consequence is secret extraction plus instantiation of side-effecting classes confined to LangChain's already-trusted namespaces (langchain_core, langchain, langchain_community). Publicly available exploit information exists in the form of the GitHub Security Advisory GHSA-c67j-w6g6-q2cm, but there is NO CISA KEV listing and NO EPSS score in the provided data, so exploitation status is 'publicly available exploit code exists' and not active exploitation. The key tension is that the headline CVSS assumes no special conditions, yet the advisory explicitly scopes exploitability to applications using astream_events(version='v1'), Runnable.astream_log(), or those that call dumps()/dumpd() on untrusted data and later deserialize with load()/loads() - so the real-world attack surface is narrower than the raw vector implies. EPSS is MISSING and cannot be compared; without it, prioritize based on whether your deployment actually exercises the affected code paths.

An attacker supplies crafted content in a user-controlled field (such as message metadata, additional_kwargs, or response_metadata) containing a dictionary with an 'lc' key that mimics LangChain's internal serialized-object marker. The application serializes this data with dumps()/dumpd() and later deserializes it via load()/loads() - for example through astream_events(version='v1') or astream_log() - causing the injected structure to be instantiated as a trusted LangChain object, enabling secret extraction or triggering side-effecting __init__ methods. Exploit details are public via the GitHub Security Advisory.