GHSA-3644-q5cj-c5c7 CVE-2026-45134 PYSEC-2026-2555 PYSEC-2026-2560 PYSEC-2026-2582
LangSmith SDK: Public prompt pull deserializes untrusted manifests without trust boundary warning
- Severity
- 7.1 / 10
- High · CVSS 3.1
- Exploit chance (EPSS)
- 0.20%
- Chance of exploitation in the next 30 days. Higher than 9.80% of scored vulnerabilities.
- Known exploited
- No
- Not in CISA's catalog
- Weakness
- CWE-502 Deserialization of Untrusted Data
- Fix
- Available
- 4 packages have a fixed version
Description
Description
The LangSmith SDK's prompt pull methods (pull_prompt / pull_prompt_commit in Python, pullPrompt / pullPromptCommit in JS/TS) fetch and deserialize prompt manifests from the LangSmith Hub. These manifests may contain serialized LangChain objects and model configuration that affect runtime behavior. When pulling a public prompt by owner/name identifier, the manifest content is controlled by an external party, but prior versions of the SDK did not distinguish this from pulling a prompt within the caller's own organization.
Prompt manifests can intentionally configure a model with a custom base URL, default headers, model name, or other constructor arguments. These are supported features, but they also mean the prompt contents should be treated as executable configuration rather than plain text. A prompt can also include serialized LangChain Runnable or PromptTemplate objects with attacker-controlled constructor kwargs, or secret references that, if secrets_from_env is enabled, read environment variables at deserialization time.
Applications are exposed when all of the following are true:
- The application calls
pull_promptorpull_prompt_commit(Python) orpullPromptorpullPromptCommit(JS/TS) with a publicowner/nameprompt identifier. - The prompt was published or modified by an untrusted or compromised account.
- The application uses the pulled prompt without independently validating its contents.
Applications that only pull prompts from their own organization (referenced by name only, without an owner/ prefix) are not affected by the public prompt trust boundary issue described above. However, same-organization prompts carry their own risk. If an attacker gains write access to the organization (for example, through a leaked LANGSMITH_API_KEY or a compromised team member account), they can push a malicious prompt that is pulled and deserialized without any additional warning.
Impact
An attacker who publishes a malicious prompt to LangSmith Hub may be able to affect applications that pull that prompt by owner/name. If the prompt manifest reaches the SDK's deserialization path, the SDK will instantiate the referenced LangChain objects with the attacker-supplied constructor arguments rather than treating the manifest as inert data.
Realistic impacts include:
- Server-side request forgery (SSRF), outbound request redirection, and interception of LLM traffic if a prompt manifest configures an LLM client with an attacker-controlled
base_url, proxy, or equivalent endpoint-setting parameter. In typical deployments, redirected requests may include prompt contents, system prompts, retrieved context, model parameters, provider credentials, or other secrets and may disclose them to the attacker-controlled endpoint. - Prompt injection or behavior manipulation if a manifest embeds attacker-controlled system messages, prompt templates, or model parameters that alter the application's behavior.
- Additional deserialization risk when
include_model=Trueis passed, because this expands the allowlist to partner integration classes. This is not the default, but it materially increases risk when pulling prompts from outside the caller's organization.
Remediation
The LangSmith SDK now blocks pulling public prompts by owner/name by default. Callers must explicitly opt in by passing dangerously_pull_public_prompt=True (Python) or dangerouslyPullPublicPrompt: true (JS/TS) to acknowledge the trust boundary. This flag should only be set after reviewing and trusting the prompt contents, not merely the publishing account.
Upgrade to LangSmith SDK Python >= 0.8.0 or JS/TS >= 0.6.0.
Guidance for prompt pull methods
The prompt pull methods (pull_prompt / pull_prompt_commit in Python, pullPrompt / pullPromptCommit in JS/TS) should be used only with trusted prompts. Do not pull public prompts by owner/name from untrusted or unreviewed sources without understanding that the manifest contents will be deserialized and may affect runtime behavior.
When pulling prompts that include model configuration (include_model=True in Python, includeModel: true in JS/TS), the deserialization allowlist expands to include partner integration classes. Because this mode is not the default and is often unnecessary for third-party prompts, prefer the default (false) when pulling prompts from sources outside your organization.
Avoid passing secrets_from_env=True (Python) when pulling untrusted prompts. This parameter allows prompt manifests to read environment variables during deserialization. Only use it with trusted prompts from your own organization.
Same-organization prompts
Prompts pulled from the caller's own organization (referenced by name only, without an owner/ prefix) are not gated by the new dangerously_pull_public_prompt flag, but they are not inherently safe. If an attacker gains write access to the organization (for example, through a leaked LANGSMITH_API_KEY or a compromised team member account), they can push a malicious prompt that redirects LLM traffic to attacker-controlled infrastructure and may disclose any credentials attached to those requests.
The security of same-organization prompts follows a shared responsibility model. The LangSmith SDK enforces trust boundaries for public prompts pulled from external accounts, but it cannot protect against compromised credentials or accounts within the caller's own organization. Securing API keys, managing team member access, and reviewing prompt contents before production deployment are the responsibility of the organization. Organizations should treat prompts as executable configuration and apply the same review and audit practices they would apply to application code.
Credits
First reported by @Moaaz-0x.
Affected versions
PyPI
| Package | Vulnerable | Fixed in |
|---|---|---|
| langchain | < 0.3.30 |
0.3.30 |
| langchain-classic | < 1.0.7 |
1.0.7 |
| langsmith | < 0.8.0 |
0.8.0 |
npm
| Package | Vulnerable | Fixed in |
|---|---|---|
| langsmith | < 0.6.0 |
0.6.0 |
How to fix
Move to the fixed version or later with your package manager, update the lockfile, and run your tests. If the package only arrives through another dependency, upgrade that dependency first. If none of its releases pulls a fixed version yet, force the version with your package manager's override.
langchain PyPI → 0.3.30
- pip
pip install --upgrade "langchain>=0.3.30"- poetry
poetry add "langchain>=0.3.30"- uv
uv add "langchain>=0.3.30"
langchain-classic PyPI → 1.0.7
- pip
pip install --upgrade "langchain-classic>=1.0.7"- poetry
poetry add "langchain-classic>=1.0.7"- uv
uv add "langchain-classic>=1.0.7"
langsmith PyPI → 0.8.0
- pip
pip install --upgrade "langsmith>=0.8.0"- poetry
poetry add "langsmith>=0.8.0"- uv
uv add "langsmith>=0.8.0"
langsmith npm → 0.6.0
- npm
npm install langsmith@0.6.0- yarn
yarn add langsmith@0.6.0- pnpm
pnpm add langsmith@0.6.0
Severity breakdown
CVSS 3.1 7.1
CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:L/A:N
- Attack vector
- Network
- Attack complexity
- Low
- Privileges required
- None
- User interaction
- Required
- Scope
- Unchanged
- Confidentiality
- High
- Integrity
- Low
- Availability
- None
Weakness
CWE-502: Deserialization of Untrusted Data
The product deserializes untrusted data without sufficiently ensuring that the resulting data will be valid.
How to prevent it
- Architecture and Design, Implementation: If available, use the signing/sealing features of the programming language to assure that deserialized data has not been tainted. For example, a hash-based message authentication code (HMAC) could be used to ensure that data has not been modified.
- Implementation: When deserializing data, populate a new object rather than just deserializing. The result is that the data flows through safe input validation and that the functions are safe.
- Implementation: Explicitly define a final object() to prevent deserialization.
- Architecture and Design, Implementation: Make fields transient to protect them from deserialization. An attempt to serialize and then deserialize a class containing transient fields will result in NULLs where the transient data should be. This is an excellent way to prevent time, environment-based, or sensitive variables from being carried over and used improperly.
- Implementation: Avoid having unnecessary types or gadgets (a sequence of instances and method invocations that can self-execute during the deserialization process, often found in libraries) available that can be leveraged for malicious ends. This limits the potential for unintended or unauthorized types and gadgets to be leveraged by the attacker. Add only acceptable classes to an allowlist. Note: new gadgets are constantly being discovered, so this alone is not a sufficient mitigation.
- Architecture and Design, Implementation: Employ cryptography of the data or code for protection. However, it's important to note that it would still be client-side security. This is risky because if the client is compromised then the security implemented on the client (the cryptography) can be bypassed.
- Operation: Use an application firewall that can detect attacks against this weakness. It can be beneficial in cases in which the code cannot be fixed (because it is controlled by a third party), as an emergency prevention measure while more comprehensive software assurance measures are applied, or to provide defense in depth [REF-1481].
References
Advisories
Packages
Other links
Timeline
- Published
- Last updated by the source
- Latest EPSS score
Related advisories
| Advisory | Severity | Why it's related |
|---|---|---|
| GHSA-gr75-jv2w-4656 LangChain: Path traversal and sandbox escape in LangChain file-search middleware and loaders | Medium | Also affects langchain |
| GHSA-45pg-36p6-83v9 Langchain SQL Injection vulnerability | Critical | Also affects langchain |
| PYSEC-2024-323 LangChain pickle deserialization of untrusted data | High | Also affects langchain |
| GHSA-3hjh-jh2h-vrg6 Denial of service in langchain-community | Medium | Also affects langchain |
| GHSA-rgp8-pm28-3759 langchain vulnerable to path traversal | High | Also affects langchain |
| GHSA-h59x-p739-982c LangChain directory traversal vulnerability | High | Also affects langchain |
| GHSA-h9j7-5xvc-qhg5 langchain Server-Side Request Forgery vulnerability | High | Also affects langchain |
| GHSA-6h8p-4hx9-w66c Langchain Server-Side Request Forgery vulnerability | High | Also affects langchain |
MergeHarbor checks every repository's dependencies against this database, ranks what matters by exploitability and reachability, routes it to the owning team and opens the fix pull request.
Check your repos with MergeHarbor