LangChain runtime paths used overly broad deserialization allowlists for agent run data
GitHub advisory GHSA-pjwx-r37v-7724 reports `CVE-2026-44843`: affected `langchain-core` runtime paths could deserialize run inputs, run outputs, or application-controlled payloads with overly broad allowlists.
Date
May 8, 2026
First Seen
May 8, 2026
Last Reviewed
May 28, 2026
Publisher
Unspecified
Source Type
Unspecified
LangChain Runtime Paths Used Overly Broad Deserialization Allowlists for Agent Run Data
Summary
GitHub advisory GHSA-pjwx-r37v-7724 reports CVE-2026-44843: affected langchain-core runtime paths could deserialize run inputs, run outputs, or application-controlled payloads with overly broad allowlists.
Why It Matters
LangChain is commonly used to build agents and LLM-powered applications. The advisory does not describe arbitrary Python object deserialization, but it does show that agent framework internals can revive trusted framework objects from application-controlled serialized constructor dictionaries when input is not canonicalized first.
For OpenClaw-style operators, the transferable risk is that agent data often flows through more than one trust boundary. User input, retrieved content, browser results, ticket text, API responses, run histories, streaming logs, and event traces can be preserved as structured data and later consumed by framework runtime code. If that later runtime boundary accepts broad serialized objects instead of an inert schema, a prompt-facing or network-facing input path can become a framework object-instantiation path.
Attack Path
- An application accepts untrusted structured input such as JSON from a user, network request, retrieval pipeline, browser tool, ticketing system, or API connector.
- The application preserves attacker-controlled nested dictionaries or lists in LangChain run inputs, outputs, message history, logs, or events.
- The application does not validate or canonicalize that data into an inert schema before a vulnerable LangChain runtime path later deserializes it.
- Affected runtime surfaces such as
RunnableWithMessageHistory,astream_log(), orastream_events(version="v1")call deserialization with overly broad object allowlists. - Trusted LangChain-serializable classes may be instantiated with attacker-controlled constructor arguments.
Affected Surface
langchain-coreversions<= 0.3.84and versions>= 1.0.0, <= 1.3.2, according to the GitHub advisory.- Patched versions are
0.3.85and1.3.3. - Applications are exposed only when they accept untrusted structured input, preserve attacker-controlled nested structures in run data, and use an affected runtime path that later deserializes that data.
- Agent control planes, coding assistants, and workflow services that store or replay run inputs, outputs, histories, events, or traces without strict schema normalization.
Operator Implications
Upgrade langchain-core to a patched version, review agent applications that accept untrusted JSON or other structured payloads, and canonicalize external input into inert schemas before passing it into LangChain runtime surfaces. Treat run history, event streams, and logs as security-relevant data flows rather than only observability artifacts.
If an affected deployment processed untrusted structured input, review logs and runtime telemetry for unusual class construction, unexpected tool behavior, suspicious outbound connections, or access to credentials and sensitive files during the vulnerable window.
Armorer Relevance
Armorer could help reduce this class of risk by giving operators a local control plane to inventory framework versions, flag vulnerable langchain-core packages, and identify agent apps that store or replay untrusted structured input through run-history, message-history, or streaming-event APIs. Docker isolation could limit filesystem and network blast radius if framework code behaves unexpectedly.
Runtime monitoring and oversight can also help: unusual object construction side effects, unexpected child processes, abnormal tool calls, outbound traffic, or credential access can be surfaced for review. Scoped credential handling and health checks would make it harder for a framework deserialization issue to turn into durable host or service compromise. These controls would not prove prevention of CVE-2026-44843, but they provide practical places to enforce and check the assumptions that agent framework runtimes depend on.
Evidence
- Source advisory: GitHub Advisory: LangChain runtime deserialization paths used overly broad allowlists.
- The advisory names
RunnableWithMessageHistory,astream_log(), andastream_events(version="v1")as known affected runtime surfaces. - The advisory lists
langchain-corepatched versions0.3.85and1.3.3. - NVD published corresponding
CVE-2026-44843metadata on 2026-05-26 with CVSS 3.1 base score 8.2 and CWE-502.
Mitigations
- Upgrade
langchain-coreto0.3.85,1.3.3, or later as appropriate for the deployed major line. - Validate and canonicalize untrusted structured input into inert schemas before invoking LangChain runtime APIs.
- Avoid preserving attacker-controlled nested dictionaries or lists directly in run inputs, outputs, histories, events, or logs.
- Treat model output, retrieval output, browser output, webhook bodies, and API connector data as untrusted until validated at the tool or framework boundary.
- Run agent apps in constrained containers with minimal filesystem, network, and credential access.
- Monitor for unusual tool calls, object-construction side effects, child processes, file access, outbound connections, and credential reads in agent runtimes.
Open Questions
- Which downstream agent products embedded affected
langchain-coreversions before the fixes. - How often agent applications replay untrusted run data through affected streaming or history APIs.
- Which Armorer health checks should become default for LangChain version inventory and run-data trust-boundary review.