A Server-Side Request Forgery (SSRF) vulnerability exists in the RequestsToolkit component of the langchain-community package (specifically, langchaincommunity.agenttoolkits.openapi.toolkit.RequestsToolkit) in langchain-ai/langchain version 0.0.27. This vulnerability occurs because the toolkit does not enforce restrictions on requests to remote internet addresses, allowing it to also access local addresses. As a result, an attacker could exploit this flaw to perform port scans, access local services, retrieve instance metadata from cloud environments (e.g., Azure, AWS), and interact with servers on the local network. This issue has been fixed in version 0.0.28.

Langchain 0.0.171 is vulnerable to Arbitrary code execution in loadprompt.

An issue in langchain allows an attacker to execute arbitrary code via the PALChain in the python exec method.

An issue in Harrison Chase langchain allows an attacker to execute arbitrary code via the PALChain,frommathprompt(llm).run in the python exec method.

Langchain 0.0.171 is vulnerable to Arbitrary Code Execution.

An issue in langchain allows a remote attacker to execute arbitrary code via the PALChain parameter in the Python exec method.

LangChain versions up to and including 0.3.1 contain a regular expression denial-of-service (ReDoS) vulnerability in the MRKLOutputParser.parse() method (libs/langchain/langchain/agents/mrkl/outputparser.py). The parser applies a backtracking-prone regular expression when extracting tool actions from model output. An attacker who can supply or influence the parsed text (for example via prompt injection in downstream applications that pass LLM output directly into MRKLOutputParser.parse()) can trigger excessive CPU consumption by providing a crafted payload, causing significant parsing delays and a denial-of-service condition.

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 allowedobjects="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:

1. The application accepts untrusted structured input, such as JSON, from a user or network request. 2. The application does not validate or canonicalize that input into an inert schema before invoking LangChain. 3. Attacker-controlled nested dictionaries or lists are preserved in LangChain run inputs or outputs. 4. The application uses an affected API path that later deserializes that run data.

Known affected runtime surfaces include:

- RunnableWithMessageHistory - astreamlog() - astreamevents(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 (islcsecret). 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.

Impact

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:

json { "lc": 1, "type": "constructor", "id": ["langchaincore", "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.

Realistic impacts include:

- Persistent chat-history poisoning when revived AIMessage, HumanMessage, or SystemMessage objects are stored by RunnableWithMessageHistory. - Prompt injection or behavior manipulation if attacker-controlled messages are later included in model context. - Instantiation of unexpected trusted LangChain objects with attacker-controlled constructor arguments. - Possible credential disclosure or server-side requests if a reachable object reads environment credentials, creates clients, or contacts attacker-controlled endpoints during initialization. - Additional prompt-template or runnable-configuration impacts in applications that separately load and execute untrusted serialized LangChain objects.

Remediation

LangChain will deprecate the affected APIs as part of this fix:

- RunnableWithMessageHistory - astreamlog() - astreamevents(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 (islcsecret). 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.

Guidance for 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 allowedobjects value appropriate for the specific trusted manifest they are loading, rather than relying on broad defaults or allowedobjects="all", which permits the full trusted LangChain serialization allowlist.

Credits

The original issue was first reported by @u-ktdi.

Similar findings were reported by @dewankpant, @shrutilohani, @Moaaz-0x, @pucagit.

A related islcsecret marker bypass affecting dumps() -> loads() round-trips was reported by @yardenporat353 (and a similar report by @localhost-detect)

With the following crawler configuration:

python from bs4 import BeautifulSoup as Soup

url = "https://example.com" loader = RecursiveUrlLoader( url=url, maxdepth=2, extractor=lambda x: Soup(x, "html.parser").text ) docs = loader.load()

An attacker in control of the contents of https://example.com could place a malicious HTML file in there with links like "https://example.completely.different/myfile.html" and the crawler would proceed to download that file as well even though preventoutside=True.

https://github.com/langchain-ai/langchain/blob/bf0b3cc0b5ade1fb95a5b1b6fa260e99064c2e22/libs/community/langchaincommunity/documentloaders/recursiveurlloader.py#L51-L51

Resolved in https://github.com/langchain-ai/langchain/pull/15559

SQL injection vulnerability in langchain allows a remote attacker to obtain sensitive information via the SQLDatabaseChain component.

LangChain is a framework for building agents and LLM-powered applications. Prior to 1.3.9, several LangChain components that resolve filesystem paths or expand search patterns do not consistently confine the resolved path to the intended root directory. Affected behaviors include: a file-search agent middleware that validates a starting directory but not the search pattern or the resolved target of matched files, so glob patterns and symlinks can reach files outside the configured root; prompt- and chain/agent-configuration loaders that accept path fields and resolve them without confining the result to a trusted base or rejecting symlink targets; and path-prefix authorization checks that compare by string prefix without a path-segment boundary, so a sibling path sharing the prefix is accepted. When these components receive path values, search patterns, or workspace contents influenced by an untrusted source — including an LLM acting on untrusted input — the result can be disclosure of files outside the intended boundary. This vulnerability is fixed in 1.3.9.