| Gói / sản phẩm | Phiên bản bị ảnh hưởng | Phiên bản đã vá |
|---|---|---|
| langchain-core | ≥ 1.0.0, < 1.3.3< 0.3.85 | 1.3.30.3.85 |
| langchain | ≥ 1.0.0, < 1.3.3< 0.3.85 | 1.3.30.3.85 |
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 load() with allowed_objects="all". This does not enable arbitrary Python object deserialization, but it does allow any trusted LangChain-serializable object to be revived, which is broader than these runtime paths require. As a result, attacker-supplied LangChain serialized constructor dictionaries may cause trusted runtime paths to instantiate classes with untrusted constructor arguments.
Applications are exposed only when all of the following are true:
Known affected runtime surfaces include:
RunnableWithMessageHistoryastream_log()astream_events(version="v1")Related unsafe deserialization patterns may also affect applications that explicitly load serialized LangChain prompt or runnable objects from untrusted sources, including shared prompt stores, Hub artifacts with model configuration, or other application-controlled serialization stores.
Applications that validate incoming requests against a fixed schema, such as coercing user input to a plain string or message-content field before invoking LangChain, are unlikely to expose this deserialization primitive.
This release also fixes a related secret-marker validation bypass in the serialization and deserialization layer (_is_lc_secret). That issue creates an additional path by which attacker-controlled constructor dictionaries can avoid escaping during dumps() -> loads() round-trips and reach LangChain object revival logic.
An attacker who can submit untrusted structured input to an affected application, and have that structure preserved in LangChain run data, may be able to inject LangChain serialized constructor payloads such as:
{
"lc": 1,
"type": "constructor",
"id": ["langchain_core", "messages", "ai", "AIMessage"],
"kwargs": {"content": "attacker-controlled content"}
}
If this payload reaches a broad load() call, LangChain may instantiate the referenced class instead of treating the payload as inert user data.
Bạn đang dùng một trong các sản phẩm này? Quét site để biết có đang lộ phiên bản có lỗ hổng không.
Quét site miễn phíRealistic impacts include:
AIMessage, HumanMessage, or SystemMessage objects are stored by RunnableWithMessageHistory.LangChain will deprecate the affected APIs as part of this fix:
RunnableWithMessageHistoryastream_log()astream_events(version="v1")These are older code paths that are no longer recommended for new applications. They were not previously marked as deprecated, but recent LangChain documentation has primarily directed users toward newer streaming and memory patterns, including the stream API. Applications should migrate to the currently recommended APIs rather than continue depending on these older surfaces.
Separately, LangChain will update load() and loads() to tighten deserialization behavior so broad object revival is not applied implicitly to untrusted or application-controlled payloads. The older runtime surfaces listed above are being deprecated rather than preserved as supported paths for broad runtime deserialization.
This release also fixes a related secret-marker validation bypass in the serialization and deserialization layer (_is_lc_secret). That issue creates an additional path by which attacker-controlled constructor dictionaries can avoid escaping during dumps() -> loads() round-trips and reach LangChain object revival logic.
load() and loads()load() and loads() should be used only with trusted LangChain manifests or serialized objects from trusted storage. Do not pass user-controlled data to load() or loads(), and do not use them as general parsers for request bodies, tool inputs, chat messages, or other attacker-controlled data.
load() and loads() are beta APIs, and their behavior may change as LangChain narrows unsafe defaults. Future LangChain versions will require callers to be explicit about which objects may be revived. Users should pass a narrow allowed_objects value appropriate for the specific trusted manifest they are loading, rather than relying on broad defaults or allowed_objects="all", which permits the full trusted LangChain serialization allowlist.
The original issue was first reported by @u-ktdi.
Similar findings were reported by @dewankpant, @shrutilohani, @Moaaz-0x, @pucagit.
A related _is_lc_secret marker bypass affecting dumps() -> loads() round-trips was reported by @yardenporat353 (and a similar report by @localhost-detect)