CVE-2026-45134

What it actually does

Affected LangSmith SDK versions deserialize prompt manifests fetched from the LangSmith Hub without adequately distinguishing externally controlled public prompts from prompts owned by the caller's organization. A malicious public prompt manifest can include serialized LangChain objects or model configuration that changes application runtime behavior when a developer or application pulls it by owner/name identifier. The primary risk is unsafe deserialization and trust-boundary confusion: externally supplied prompt content may influence model chains, tool configuration, prompts, or execution flow inside the consuming application. The CVSS vector indicates network reachability, low attack complexity, no attacker privileges required, but user interaction is required because a target must pull or reference the malicious public prompt.

Why it matters to the business

Organizations that use LangSmith SDKs to import public prompts could unintentionally run AI workflow configuration controlled by an outside party. This can lead to exposure of sensitive prompt context, unwanted changes to application behavior, data leakage through model or tool configuration, or integrity issues in AI-assisted business processes. The issue is not currently listed in CISA KEV, has no known mature public exploit, and has a low EPSS score, but it should still be remediated because affected SDKs may be embedded in developer tooling, AI applications, CI jobs, notebooks, and production services that dynamically pull prompts.

How an attack unfolds

An attacker publishes or controls a public LangSmith Hub prompt under an owner/name identifier that a victim is likely to use, copy, or reference. The prompt manifest contains serialized LangChain objects or model configuration crafted to alter runtime behavior when deserialized by a vulnerable LangSmith SDK. A developer, notebook, service, or automation job using an affected SDK version calls pull_prompt or pull_prompt_commit in Python, or pullPrompt or pullPromptCommit in JavaScript/TypeScript, against that public identifier. Because the SDK treats externally controlled public prompt content similarly to trusted organizational content, the manifest is fetched and deserialized. The resulting object or configuration can then influence downstream prompt execution, chain composition, model settings, tool usage, or data flow in the consuming application. Successful exploitation depends on the target pulling the malicious prompt; there is no indication from the provided intelligence that this is being actively exploited in the wild.

How to fix it

Upgrade affected LangSmith SDKs to fixed versions or later: LangSmith SDK for Python version 0.8.0 or later, and LangSmith SDK for JavaScript/TypeScript version 0.6.0 or later. Pin minimum versions in dependency manifests and lockfiles to prevent downgrade or transitive reintroduction. Review code paths that dynamically pull public prompts by owner/name identifier and prefer immutable, reviewed prompt commits where possible. Treat public prompt manifests as untrusted input; only pull prompts from trusted owners, validate prompt identifiers through allowlists, and avoid automatic runtime pulls from public sources in production. If immediate upgrade is not possible, disable or restrict public prompt pulling, require manual review of manifest content before use, and prevent production workloads from fetching prompts from untrusted LangSmith Hub namespaces.

How to confirm the fix worked

Confirm that all Python environments using the LangSmith SDK report version 0.8.0 or later, and all JavaScript/TypeScript projects report version 0.6.0 or later. Check dependency files such as requirements.txt, pyproject.toml, poetry.lock, Pipfile.lock, package.json, package-lock.json, yarn.lock, and pnpm-lock.yaml for older langsmith package versions. Search application code for affected APIs, including pull_prompt, pull_prompt_commit, pullPrompt, and pullPromptCommit, and verify that any public prompt references are trusted, pinned, and reviewed. In CI/CD, add dependency policy checks that fail builds when langsmith versions are below the fixed releases. Where egress logs are available, verify that production services are not unexpectedly pulling public prompt manifests at runtime.

Typical attack path

1. Attacker creates or compromises a public LangSmith Hub prompt repository under an owner/name identifier.
2. Attacker crafts the prompt manifest to include serialized LangChain objects or model configuration that affects runtime behavior after deserialization.
3. Attacker persuades a developer, application, notebook, CI job, or automation workflow to pull the public prompt, or relies on typo/confusion with a legitimate prompt identifier.
4. The vulnerable SDK method fetches the public manifest using pull_prompt, pull_prompt_commit, pullPrompt, or pullPromptCommit.
5. The SDK deserializes externally controlled manifest content without the fixed trust-boundary protections.
6. The consuming application uses the deserialized prompt, chain, or configuration, allowing attacker-controlled behavior to affect AI workflow execution or data handling.

How to detect it

There are no provided indicators of active exploitation, named threat actors, or known exploit tooling for this issue. To assess whether exposure or attempted exploitation occurred, review source control history, CI logs, notebook execution logs, application logs, dependency manifests, and outbound proxy/DNS logs for use of affected SDK versions and public prompt pulls. Focus on calls to pull_prompt, pull_prompt_commit, pullPrompt, and pullPromptCommit, especially where the prompt identifier is an owner/name string outside the organization's trusted namespaces. Look for recent additions of public prompt references, prompt owner/name values that resemble typo-squatting, unexpected prompt commit changes, or prompt manifests containing unusual serialized LangChain objects, tool definitions, model endpoints, callbacks, retrievers, or configuration that could redirect data flow. Review package lockfiles and container images to determine whether vulnerable SDK versions were present during the period when suspicious prompt pulls occurred. If application telemetry captures prompt pulls or LangSmith SDK activity, correlate prompt identifiers, commit hashes, caller process, deployment version, and outbound connections to determine whether an externally controlled manifest was fetched and then used by an application workflow.

• pull_prompt
• pull_prompt_commit
• pullPrompt
• pullPromptCommit
• langsmith<0.8.0
• langsmith@<0.6.0
• from langsmith import Client
• require('langsmith')
• from "langsmith"
• serialized LangChain objects
• LangSmith Hub

What your security team should do

• Inventory all repositories, notebooks, containers, and runtime images that include the LangSmith SDK for Python or JavaScript/TypeScript.
• Upgrade Python langsmith to 0.8.0 or later and JavaScript/TypeScript langsmith to 0.6.0 or later, then rebuild and redeploy affected artifacts.
• Search source code and scheduled jobs for pull_prompt, pull_prompt_commit, pullPrompt, and pullPromptCommit, prioritizing production services and CI workflows that pull prompts dynamically.
• Establish an allowlist of trusted LangSmith Hub owners or prompt identifiers and block unreviewed public prompt pulls in production environments.
• Review recently added or modified public prompt references for suspicious owner/name values, typo-squatting, unexpected commits, or changes in model/tool configuration.
• Add dependency scanning rules for vulnerable langsmith versions and enforce minimum fixed versions in package management policy.
• Monitor outbound network activity and application logs for unexpected LangSmith Hub prompt pulls from production or privileged environments.
• Educate AI application developers that public prompt manifests are third-party code/configuration inputs and should be reviewed before use.