CVE-2026-40190

What it actually does

The LangSmith JavaScript/TypeScript SDK before version 0.5.18 contains an incomplete prototype-pollution defense in a vendored lodash set() implementation used by createAnonymizer(). The code blocks the __proto__ key but does not block traversal through constructor.prototype, allowing attacker-controlled property paths to write to Object.prototype. In a Node.js process, this can cause newly created or existing plain objects to inherit attacker-defined properties, potentially altering application logic, corrupting data handling, weakening security checks, or causing application instability. The vulnerability does not inherently provide remote code execution by itself, but impact can increase if the host application contains exploitable prototype-pollution gadgets.

Why it matters to the business

Applications that use vulnerable LangSmith SDK versions and pass untrusted or externally influenced keys into createAnonymizer() may have runtime behavior changed unexpectedly. This can lead to incorrect data anonymization, authorization or validation bypasses in vulnerable application code, data integrity issues, service instability, and incident-response costs. Current public exploitation signals are low: EPSS is 0.00313 and stable over 30 days, the issue is not in CISA KEV, and no exploit maturity is reported; however, the fix should still be prioritized for applications that process user-controlled LangSmith tracing, metadata, or anonymization inputs.

How an attack unfolds

An attacker first finds an application path where user-controlled data, metadata, trace content, field names, or JSON keys are processed by the LangSmith JavaScript/TypeScript SDK createAnonymizer() API. Instead of using a direct __proto__ key, which is blocked, the attacker supplies a crafted nested key path using constructor.prototype. When the vulnerable vendored set() utility processes that path, it writes attacker-chosen properties onto Object.prototype. Those properties then become visible through prototype inheritance across ordinary objects in the same Node.js process. The attacker’s practical impact depends on how the surrounding application uses object properties: they may influence conditionals, defaults, validation decisions, serialization, anonymization behavior, or cause crashes. Successful exploitation generally requires knowledge of a useful application-specific property or gadget, which is why attack complexity is high.

How to fix it

Upgrade the LangSmith JavaScript/TypeScript SDK package langsmith to version 0.5.18 or later. Regenerate and redeploy lockfiles so production builds actually consume the fixed package. If immediate upgrade is not possible, avoid passing untrusted keys into createAnonymizer(), reject dangerous path segments such as constructor, prototype, and __proto__, and validate anonymizer input against an explicit allowlist of expected keys. Consider adding runtime hardening and tests that assert Object.prototype is not modified after processing untrusted data. Because prototype pollution can persist for the lifetime of a Node.js process, restart affected services after upgrading or applying mitigations.

How to confirm the fix worked

Confirm dependency resolution shows langsmith version 0.5.18 or later in package-lock.json, npm-shrinkwrap.json, yarn.lock, pnpm-lock.yaml, and deployed node_modules/langsmith/package.json. Run package-manager checks such as npm ls langsmith, yarn why langsmith, or pnpm why langsmith to identify direct and transitive installations. Add a regression test that sends a constructor.prototype-style key through any createAnonymizer() wrapper and verifies that Object.prototype does not receive the supplied property. For runtime validation, inspect deployed containers, serverless bundles, and build artifacts to ensure no vulnerable bundled copy remains. Restart Node.js services after validation to clear any in-memory polluted prototype state from prior execution.

Typical attack path

1. Identify a Node.js application using the LangSmith JavaScript/TypeScript SDK version earlier than 0.5.18.
2. Find an input path where attacker-controlled object keys or field paths are passed into createAnonymizer().
3. Submit crafted data containing a constructor.prototype traversal path with attacker-selected property names and values.
4. Trigger the vulnerable vendored set() behavior so the property is assigned to Object.prototype.
5. Abuse inherited polluted properties to alter application behavior, corrupt anonymization or processing logic, bypass weak checks, or degrade availability.
6. Repeat or refine payloads to target application-specific prototype-pollution gadgets.

How to detect it

Review application, API gateway, WAF, and Node.js service logs for requests or payloads containing constructor.prototype or other prototype-pollution path segments near endpoints that ingest LangSmith traces, metadata, feedback, datasets, or anonymization-related input. Inspect error logs for sudden TypeError exceptions, unexpected boolean/string values on ordinary objects, anomalous anonymization output, or behavior changes immediately after processing untrusted JSON. Search source logs, request bodies retained in observability systems, message queues, and dead-letter queues for crafted nested keys. In forensic analysis, check deployed dependency versions and inspect running process behavior by testing whether unexpected attacker-like properties exist on Object.prototype. Because pollution may only exist in memory and disappear after process restart, absence of files on disk does not rule out prior exploitation. No public threat actor or KEV exploitation is currently associated with this issue, so detection should focus on payload patterns and application-specific symptoms rather than known campaign infrastructure.

• constructor.prototype
• constructor[prototype]
• constructor.prototype.
• constructor.prototype.polluted
• __proto__
• prototype.polluted
• createAnonymizer
• node_modules/langsmith/package.json
• "langsmith"
• "version":"0.5.17"
• "version": "0.5.17"
• "version":"0.5.16"
• "version": "0.5.16"
• "version":"0.5.15"
• "version": "0.5.15"

What your security team should do

• Inventory all JavaScript and TypeScript services, workers, serverless functions, and build artifacts that include the langsmith package.
• Upgrade langsmith to 0.5.18 or later and verify lockfiles and deployed artifacts, not only package.json declarations.
• Prioritize remediation where LangSmith inputs, trace metadata, JSON fields, anonymization configuration, or user-generated content can influence createAnonymizer() keys.
• Add input validation that rejects prototype-pollution path segments including constructor, prototype, and __proto__ before data reaches generic object setters.
• Search logs and telemetry for suspicious constructor.prototype payloads and unexpected object-property behavior around LangSmith processing paths.
• Add unit or integration tests for prototype-pollution resistance in any code that wraps LangSmith anonymization or processes dynamic object paths.
• Restart affected Node.js processes after patching to remove any polluted in-memory Object.prototype state.
• Track vendor advisories and dependency-scanning results even though the issue is not currently in CISA KEV and has low, stable EPSS.