CVE-2026-44843

What it actually does

LangChain versions before 0.3.85 and 1.3.3 include legacy runtime paths that deserialize run inputs, run outputs, or other application-controlled LangChain-serialized payloads with an overly broad object allowlist, including code paths that may call load() with allowed_objects="all". The issue does not provide arbitrary Python object deserialization, but it can allow attacker-controlled serialized constructor dictionaries to revive trusted LangChain-serializable classes with untrusted constructor arguments. In affected applications, this can lead to unintended object instantiation, exposure of sensitive data through trusted components, and limited integrity impact depending on which LangChain objects and application integrations are reachable.

Why it matters to the business

An exposed LLM application or agent workflow that accepts attacker-controlled LangChain serialized data may be manipulated into constructing unintended trusted objects, potentially exposing sensitive prompts, run data, credentials passed through application components, or downstream integration data. The CVSS score is high, but the issue is not currently listed in CISA KEV, is not known to be used in ransomware campaigns, and has low EPSS, indicating limited public exploitation signal at this time. Because LangChain is commonly embedded inside AI applications and agent orchestration systems, impact depends heavily on whether untrusted users can submit serialized LangChain payloads to affected runtime paths.

How an attack unfolds

An attacker first identifies an application endpoint, API, worker, queue, callback handler, or tracing/runtime feature that accepts LangChain serialized inputs, outputs, or run metadata from an untrusted source. The attacker then submits a crafted LangChain serialized constructor dictionary that references a trusted LangChain-serializable class rather than an arbitrary Python object. In vulnerable versions, legacy deserialization logic may process the payload using an overly broad allowlist such as allowed_objects="all", causing the runtime to instantiate that trusted class with attacker-controlled constructor arguments. The resulting impact depends on the class instantiated and how the application uses the object: it may cause sensitive data access, unexpected outbound requests, altered chain or tool behavior, or other application-level side effects. There is no current public exploit maturity indicated, and exploitation requires a reachable application path that deserializes attacker-controlled LangChain serialization data.

How to fix it

Upgrade LangChain to a fixed release: use 0.3.85 or later on the 0.3.x line, or 1.3.3 or later on the 1.x line. If immediate upgrade is not possible, block untrusted users from supplying LangChain serialized constructor dictionaries, run inputs, run outputs, or serialized object payloads to runtime deserialization paths. Review application code for calls to LangChain deserialization helpers that use overly broad allowlists, especially load() with allowed_objects="all", and replace them with narrow allowlists of only the specific object types required. Treat serialized LangChain payloads as untrusted input, validate structure before deserialization, and isolate agent/tool execution from secrets and privileged integrations.

How to confirm the fix worked

Confirm the deployed LangChain package version is 0.3.85 or later, or 1.3.3 or later, using package inventory, lockfiles, container images, and runtime environment checks. Search application code and dependencies for deserialization calls using allowed_objects="all" or broad object allowlists. Verify that public or partner-facing endpoints cannot submit raw LangChain serialized payloads unless strictly authenticated, authorized, schema-validated, and deserialized with a narrow allowlist. In test environments, submit benign LangChain serialized constructor payloads and confirm they are rejected unless the referenced object type is explicitly required and allowed.

Typical attack path

1. Identify an AI application, agent service, API, worker, or integration using affected LangChain versions before 0.3.85 or 1.3.3.
2. Find a reachable path that accepts LangChain serialized run inputs, run outputs, traces, callbacks, saved objects, or application-controlled payloads from an untrusted source.
3. Craft a LangChain serialized constructor dictionary referencing a trusted LangChain-serializable object type.
4. Supply attacker-controlled constructor arguments intended to change runtime behavior, access sensitive data, or trigger side effects.
5. Submit the payload to the vulnerable deserialization path.
6. Leverage the instantiated object’s behavior inside the application workflow to obtain data exposure or limited integrity impact.

How to detect it

To determine whether exploitation already occurred, review application access logs, API gateway logs, worker queue payload logs, LangChain tracing or callback logs, and application error logs for unexpected LangChain serialized constructor dictionaries submitted by users or external clients. Focus on endpoints or jobs that ingest run inputs, run outputs, serialized chains, serialized tools, traces, callbacks, or saved agent state. Look for JSON payloads containing LangChain serialization markers such as constructor object types, id arrays referencing langchain classes, or unusually complex object graphs in fields that normally contain plain text prompts or simple metadata. Review logs for unexpected outbound requests, unusual tool invocation, unexpected class names during deserialization, validation errors, or exceptions raised while constructing LangChain objects. If detailed request bodies are not logged, investigate anomalous requests by size, content type, repeated 4xx/5xx responses around AI workflow endpoints, or unexplained agent behavior immediately preceding data access anomalies.

• allowed_objects="all"
• allowed_objects='all'
• "type":"constructor"
• "type": "constructor"
• "lc":1
• "lc": 1
• "id":["langchain"
• "id": ["langchain"
• "kwargs":{
• "kwargs": {
• load() got an unexpected
• Error loading object
• Invalid serialized object
• LangChain serialized

What your security team should do

• Prioritize inventory of applications, services, notebooks, workers, and containers that embed LangChain and accept user-controlled workflow, trace, run, or serialized object data.
• Upgrade affected LangChain deployments to 0.3.85 or later, or 1.3.3 or later, through dependency manifests and rebuilt runtime images.
• Search source code for load() calls and any deserialization logic using allowed_objects="all"; replace with narrow allowlists.
• Restrict external access to endpoints that ingest LangChain serialized payloads, run metadata, or agent state until patched.
• Add application-level logging around deserialization failures, unexpected constructor object types, and rejected serialized payloads.
• Review secrets, tool permissions, and outbound network access available to LangChain agents so unintended object construction cannot easily expose high-value data.
• Because the issue is not KEV-listed and EPSS is low, handle as high-priority patching for exposed AI applications rather than emergency incident response unless suspicious payloads are observed.