Loading story…
LangChain disclosed and patched CVE-2026-44843, an unsafe deserialization flaw in older runtime code paths that processed application-controlled run inputs, run outputs, and related payloads with overly broad load() allowlists. In versions prior to 0.3.85 and 1.3.3, some paths could call load() with allowed_objects="all", allowing attacker-supplied serialized constructor dictionaries to revive trusted LangChain-serializable objects instead of only the narrowly required classes. The issue does not enable arbitrary Python object deserialization, but it can still instantiate trusted LangChain classes with untrusted arguments.
LangChain said exploitation requires applications to accept untrusted structured input, preserve nested attacker-controlled data in run data, and use vulnerable deserialization paths such as RunnableWithMessageHistory, astream_log(), or astream_events(version="v1"). The company warned the flaw could lead to persistent chat-history poisoning, prompt manipulation, unexpected object instantiation, and in some cases credential disclosure or server-side requests during object initialization. The fixes tighten load() and loads() behavior, address a related _is_lc_secret validation bypass, and are accompanied by guidance to migrate away from deprecated APIs and restrict deserialization to trusted manifests with narrow allowed_objects settings.
Track how attackers are adapting to this technology.
2 events from the most recent confirmed update back to the earliest known activity.
The unsafe deserialization issue was publicly tracked as CVE-2026-44843, describing exposure in LangChain versions prior to 0.3.85 and 1.3.3. The CVE entry noted that the flaw could instantiate trusted LangChain classes from attacker-supplied constructor dictionaries, but did not permit arbitrary Python object deserialization.
LangChain addressed a vulnerability in older runtime deserialization paths that used overly broad load() allowlists, allowing attacker-controlled serialized LangChain objects to be revived in certain application flows. The fix tightened load()/loads() behavior, deprecated affected older APIs, and also corrected a related _is_lc_secret validation bypass.
Vulnerabilities, threat actors, malware, products, organizations, and breaches Mallory has linked to this story.
Follow how adversaries are adapting to this technology, and where it touches your stack today.
2 references tracked. Mallory keeps watching after this page renders.
cvefeed.io
Open sourcegithub.com
Open sourceMap indicators from this story to your assets and identify affected systems in minutes.
Every observed campaign, victim, and pivot linked to actors named in this story.
Malware, exploits, and IOCs connected to the activity described here.
YARA, Sigma, and Snort rules deployed to your SIEM as soon as they’re published.
Get matching new stories delivered to your team as they break — not the next morning.
Ask questions about this story and take action on the answers.
Other stories Mallory is tracking that overlap on entities, sources, or topic labels.
Two critical serialization injection vulnerabilities were discovered in the LangChain framework, which is widely used for building LLM-powered applications. The first vulnerability (CVE-2025-68665) affects the `toJSON()` method in LangChain JS and related serialization routines, where user-controlled data containing the reserved `lc` key could be misinterpreted as legitimate LangChain objects during deserialization. The second vulnerability (CVE-2025-68664) impacts the `dumps()` and `dumpd()` functions, allowing attacker-supplied dictionaries with the `lc` key to be treated as internal objects, potentially leading to the extraction of secrets or the instantiation of internal classes with attacker-defined parameters. Both vulnerabilities are remotely exploitable and have been patched in recent versions of LangChain and LangChain Core. Exploitation of these flaws could allow attackers to extract sensitive information such as environment variables or manipulate application behavior by injecting malicious data structures. Organizations using affected versions of LangChain are strongly advised to upgrade to the patched releases—@langchain/core versions 0.3.80 and 1.1.8, langchain versions 0.3.37 and 1.2.3 for CVE-2025-68665, and langchain-core 0.3.81 and 1.2.5 for CVE-2025-68664—to mitigate the risk of exploitation.
Jun 29, 2026
A **critical deserialization vulnerability** tracked as `CVE-2025-68664` was disclosed in LangChain, affecting the framework's `dumps()` and `dumpd()` serialization functions. The flaw stems from improper escaping of dictionaries containing the internal `lc` key, allowing attacker-controlled input to be interpreted as trusted LangChain objects during deserialization. GitHub's advisory describes the issue as a serialization injection bug that can expose secrets through the `dumps`/`loads` APIs, while Red Hat warns the same weakness can lead to **remote arbitrary code execution**. Red Hat assigned the issue a **CVSS v3 score of 9.3** and classified it as `CWE-502` (**Deserialization of Untrusted Data**), while NVD scored it **8.2**. Red Hat said fixes were issued for affected products including **Red Hat Ansible Automation Platform 2.4, 2.5, and 2.6**, as well as **Red Hat OpenShift Lightspeed 1.1.2**, through security errata released in January 2026. The vulnerability is also tracked in the official CVE record under `CVE-2025-68664`.
Aug 20, 2026
German CERT advisories disclosed two vulnerabilities in **LangChain**, warning that the framework is affected by flaws that can lead to **information disclosure** and the **bypassing of security measures**. The issues were published in separate notices, identified as `2026-0877` and `2026-1010`, indicating multiple security weaknesses affecting the widely used LLM application framework. The advisories provide limited public detail, but the reported impact suggests attackers could expose sensitive data and circumvent protections built into LangChain-based deployments. Organizations using LangChain should review the affected advisories, identify exposed implementations, and prioritize vendor guidance, patching, and compensating controls to reduce the risk of data exposure and weakened application security.
Jun 29, 2026