LangSmith SDK Arbitrary File Read - GHSA-f4xh-w4cj-qxq8

GHSA-f4xh-w4cj-qxq8 is an arbitrary file read in the LangSmith SDK, the langsmith package on PyPI, rated High with no CVE assigned. The TracingMiddleware merges HTTP tracing-propagation headers into run data without proper validation, letting an attacker inject run attributes and specify an arbitrary file path that the server then reads and uploads as a trace attachment. The flaw affects langsmith before 0.8.18 and is fixed in 0.8.18, and carries CWE-22 path traversal, CWE-346 origin validation, and CWE-843 type confusion. This advisory covers what the bug exposes, why a tracing SDK is an agentic-endpoint problem, and how Anomity surfaces and governs the agents that carry it.

What happened

The LangSmith SDK is the tracing and observability layer that teams wire into LangChain agents to capture runs, inputs, and outputs. Its TracingMiddleware reads tracing-propagation headers off incoming HTTP requests so a trace can be stitched together across services. Those headers are where the trust boundary breaks.

In the affected versions, the middleware merges those HTTP tracing-propagation headers into run data without proper validation. That merge lets an attacker inject run attributes, including file attachments. A type-checking mechanism that is meant to restrict filesystem access fails to engage because of a mismatch between the expected and the actual type of the decoded input, so the guard that should have blocked a file path never runs.

The result is arbitrary file read. An attacker can specify an arbitrary file path through a crafted HTTP request, causing the server to read that file and upload its contents to LangSmith as a trace attachment. Because the server performs the read, the attacker inherits the service process's filesystem access, and the file lands where anyone with workspace trace-read permissions can see it, exposing configuration, credential material, or source to a wider audience than ever intended.

The remediation is a version upgrade: langsmith is fixed in 0.8.18, so every endpoint and service that runs the SDK should move to 0.8.18 or later. Until then, any service that accepts external HTTP requests with LangSmith tracing enabled should be treated as exposed.

Why this is an agentic-endpoint risk

LangSmith is not a standalone product on the endpoint; it is the tracing SDK wired directly into LangChain agents. When a team turns on observability, the langsmith package rides along inside the agent service, and its TracingMiddleware sits in the request path. A middleware that reads an arbitrary file and uploads it as a trace attachment is a data-exposure flaw living inside the agent's own instrumentation, the very layer teams add to gain visibility.

That placement is the risk. The leak is driven by the request itself: a crafted HTTP request carrying tracing-propagation headers, whether from an external caller, a poisoned upstream, or a compromised dependency in the chain, can steer the server to read a file it should never surface. Network and EDR controls see an HTTP request and an outbound upload to a tracing backend, but cannot tell you which agents on which endpoints run an affected langsmith build, or whether tracing is even enabled on the service that just leaked a file.

This is the same artifact-layer blind spot we track across the framework cluster, including LangChain unsafe deserialization - CVE-2026-44843, LangChain prompt template injection - CVE-2026-40087, LlamaIndex SQL injection - CVE-2025-1793, and the MLflow AI Gateway secrets exfiltration - CVE-2026-4035 case, where an observability or gateway path becomes a data-exposure vector. Because the flaw can read credential material off disk, it also intersects the concerns in secrets management for AI agents. The SDK is one node in a graph of AI artifacts, and you can't govern what you can't see. Fleet-wide inventory of every AI artifact is the precondition for scoping a file-read exposure like this one.

How Anomity surfaces and governs it

Anomity inventories eight AI artifact types on every managed endpoint: AI agents, MCP servers, extensions, skills, plugins, secrets, hooks, and CLIs. For GHSA-f4xh-w4cj-qxq8 that means the agents and CLIs carrying the LangSmith SDK are catalogued alongside the version each runs, so you can answer "which endpoints run an affected langsmith build, and what talks to it" from the fleet inventory instead of guessing whether tracing was ever enabled.

On agents that expose a hook, such as Claude Code PreToolUse, Anomity returns allow, deny, or log on each tool call before it runs. That is the enforcement point in runtime governance: a tool call that would drive an affected tracing path can be denied or logged in line rather than discovered after a file has already been uploaded as a trace attachment. Anomity collects metadata only and redacts secrets on the endpoint, so any file contents the read tried to reach never pass through Anomity.

Every decision is written to a queryable 90-day audit trail. After a disclosure like this, that trail is what lets responders scope the event: which agents ran an affected version, when, and what each did. Anomity routes those decisions to SIEM, Slack, email, or Jira so the right team sees them in the tool they already use. The result is the timeline and the enforcement record described under outcomes.

Anomity complements your existing Network, EDR, DLP, and GRC controls rather than replacing them. It adds the agentic-endpoint layer those tools cannot see. See how it works and how Anomity compares for where it fits, and the same artifact-layer discipline applies to securing AI coding agents and CLIs and to MCP server security.

What to check across your fleet

• Identify every endpoint and service that carries the langsmith package and record the exact version; treat anything below 0.8.18 as affected.
• Upgrade langsmith to 0.8.18 or later, and confirm no older build lingers in a pinned virtual environment, lockfile, or container image.
• Enumerate which agent services have LangSmith tracing enabled and accept external HTTP requests, since those are the exposed instances.
• Restrict and authenticate the request paths that reach TracingMiddleware so untrusted callers cannot supply tracing-propagation headers.
• Review LangSmith workspace trace attachments for unexpected file contents, and tighten who holds workspace trace-read permissions.
• Rotate any credentials or secrets stored on disk on affected hosts, since arbitrary file read may have surfaced them as trace attachments.
• Enumerate which AI agents and CLIs depend on the LangSmith SDK using a fleet-wide AI artifact inventory rather than manual dependency review.
• Confirm hook-based allow/deny/log enforcement is active on agents that carry the SDK, so a call reaching an affected tracing path can be blocked before it runs.

GHSA-f4xh-w4cj-qxq8 turns a crafted tracing header into an arbitrary file read that surfaces internal files as trace attachments, which is exactly why the AI artifact layer needs its own inventory and enforcement. For the full cluster context, see the pillar on securing AI agent frameworks. To see Anomity inventory your agents, govern tool calls at the hook, and keep a 90-day audit trail, request early access.