<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/"><channel><title>Langchain-Core — CraftedSignal Threat Feed</title><link>https://feed.craftedsignal.io/products/langchain-core/</link><description>Trending threats, MITRE ATT&amp;CK coverage, and detection metadata. Fed continuously.</description><generator>Hugo</generator><language>en</language><managingEditor>hello@craftedsignal.io</managingEditor><webMaster>hello@craftedsignal.io</webMaster><lastBuildDate>Thu, 04 Jan 2024 18:00:00 +0000</lastBuildDate><atom:link href="https://feed.craftedsignal.io/products/langchain-core/feed.xml" rel="self" type="application/rss+xml"/><item><title>LangChain Unsafe Deserialization Vulnerability</title><link>https://feed.craftedsignal.io/briefs/2024-01-04-langchain-deserialization/</link><pubDate>Thu, 04 Jan 2024 18:00:00 +0000</pubDate><author>hello@craftedsignal.io</author><guid isPermaLink="true">https://feed.craftedsignal.io/briefs/2024-01-04-langchain-deserialization/</guid><description>LangChain is vulnerable to unsafe deserialization of attacker-controlled objects through overly broad `load()` allowlists, potentially leading to persistent chat-history poisoning, prompt injection, credential disclosure, or server-side requests.</description><content:encoded><![CDATA[<p>LangChain contains older runtime code paths that deserialize run inputs, run outputs, or other application-controlled payloads using overly broad object allowlists. These paths may call <code>load()</code> with <code>allowed_objects='all'</code>, allowing any trusted LangChain-serializable object to be revived with attacker-supplied constructor arguments. The vulnerability exists when applications accept untrusted structured input (e.g., JSON), fail to validate it before invoking LangChain, preserve attacker-controlled nested dictionaries/lists in LangChain run data, and use affected API paths like <code>RunnableWithMessageHistory</code>, <code>astream_log()</code>, or <code>astream_events(version=&quot;v1&quot;)</code>. A related secret-marker validation bypass in the serialization layer also contributes to the issue. This vulnerability affects <code>langchain-core</code> versions &gt;= 1.0.0 and &lt;= 1.3.2, as well as versions &lt;= 0.3.84.</p>
<h2 id="attack-chain">Attack Chain</h2>
<ol>
<li>The attacker crafts a malicious JSON payload containing a LangChain serialized constructor dictionary, e.g., for an <code>AIMessage</code> object with attacker-controlled content.</li>
<li>The attacker submits the crafted JSON payload to a vulnerable application endpoint that accepts structured input.</li>
<li>The application, without proper validation or canonicalization, processes the untrusted input and passes it to LangChain.</li>
<li>The attacker-controlled nested dictionaries or lists are preserved in LangChain run inputs or outputs.</li>
<li>The application invokes an affected API path, such as <code>RunnableWithMessageHistory</code>, <code>astream_log()</code>, or <code>astream_events(version=&quot;v1&quot;)</code>, which uses <code>load()</code> with a broad object allowlist.</li>
<li>LangChain deserializes the malicious payload, instantiating the attacker-specified object (e.g., <code>AIMessage</code>) with attacker-controlled constructor arguments.</li>
<li>The instantiated object&rsquo;s content is then used in subsequent application logic, potentially leading to prompt injection, chat history poisoning, or other malicious outcomes.</li>
<li>If the instantiated object reads environment credentials, creates clients, or contacts attacker-controlled endpoints during initialization, credential disclosure or server-side request forgery may occur.</li>
</ol>
<h2 id="impact">Impact</h2>
<p>Successful exploitation allows an attacker to inject LangChain serialized constructor payloads, potentially leading to persistent chat-history poisoning (if revived messages are stored by <code>RunnableWithMessageHistory</code>), prompt injection, or the instantiation of unexpected LangChain objects with attacker-controlled arguments. This may lead to credential disclosure, server-side request forgery, or further exploitation within the application. The number of affected applications is currently unknown, but the impact could be significant given the widespread use of LangChain.</p>
<h2 id="recommendation">Recommendation</h2>
<ul>
<li>Migrate away from the deprecated APIs: <code>RunnableWithMessageHistory</code>, <code>astream_log()</code>, and <code>astream_events(version=&quot;v1&quot;)</code> to the newer, recommended streaming and memory patterns.</li>
<li>Update LangChain to a patched version that tightens deserialization behavior.</li>
<li>Do not pass user-controlled data to <code>load()</code> or <code>loads()</code>. Only use these functions with trusted LangChain manifests or serialized objects from trusted storage.</li>
<li>Use a narrow <code>allowed_objects</code> value appropriate for the specific trusted manifest being loaded, instead of relying on broad defaults or <code>allowed_objects=&quot;all&quot;</code>.</li>
<li>Deploy the Sigma rule to detect suspicious process creation involving deserialization of LangChain objects.</li>
</ul>
]]></content:encoded><category domain="severity">high</category><category domain="type">advisory</category><category>langchain</category><category>deserialization</category><category>vulnerability</category></item></channel></rss>