Home/ Blog/ Security news/ Article
Blog · Security news

One tracing header can make a LangSmith server hand over its files

LangSmith SDK before 0.8.18 lets a crafted tracing header read arbitrary files off any server running TracingMiddleware. Upgrade now; it is the second such bug.

Isometric sealed server with a ribbon carrying one document out a side port

If you build on LangChain and have LangSmith tracing switched on, upgrade the langsmith Python package to 0.8.18 now. A flaw made public on June 19, 2026 turns one crafted web request into a file leak: reach a server's TracingMiddleware over the network, point it at a path, and the server reads that file off its own disk and ships the bytes back out as a trace attachment. The bug carries advisory ID GHSA-f4xh-w4cj-qxq8 and a 7.7 out of 10 (high) rating. There is no CVE number, so file it under the advisory ID.

One bug is routine. The detail that should make you sit up is that this is the second time in 2026 the same piece of LangSmith, its distributed tracing, has trusted something a stranger handed it.

How the file walks out

Distributed tracing follows a single request as it bounces between services. To stitch the hops together, each call carries a few small headers that name the trace it belongs to. The unspoken assumption baked into that design is that those headers come from your own cooperating systems, never from an outsider.

According to the project's own write-up, TracingMiddleware leaned on that assumption twice over, and two small mistakes lined up:

  • One of those trace headers could smuggle in extra attributes for the recorded run, attachments among them, and nothing checked whether they belonged there. So an attacker gets to name a file.

  • A guard meant to stop the code from touching the filesystem was looking for the wrong data type, so it quietly waved the request through. So the named file actually gets opened.

Chain the two and the result is mechanical: the header picks a file, the dead guard lets it through, and the background tracing thread mails the contents off as an attachment.

Who can pull this off

The attack splits across two roles, and the split is the whole nuance. Kicking off the read takes no credentials at all, just network reach to the middleware. Collecting the stolen file is the gated part: you need permission to read traces in the LangSmith workspace they land in. The advisory calls this a trust-boundary crossing, and rightly so. A junior workspace member, an outside contractor, or one hijacked teammate account, people with no business reading a production server's disk, end up able to do exactly that.

That sounds like a tidy limit. In practice it often is not. Trace-read access tends to get sprinkled around freely, because traces look like throwaway debug output. When more people can read your workspace than can SSH into your boxes, the real exposure runs well past what a 7.7 implies.

Why the repeat is the real story

February brought CVE-2026-25528, a server-side request forgery (SSRF) bug, the class where a server is fooled into making network calls for the attacker. There, a doctored baggage header set the destination address, and trace data, model prompts and completions included, could be funneled to a box the attacker owned. The fix landed in langsmith 0.6.3.

Look past the surface and both bugs are the same mistake wearing different clothes. The tracing layer kept reading attacker-supplied headers as if they were trusted settings. In February the lever was where data got sent. In June it is which local file gets opened. Strip away the specifics and you are left with one bad call repeated: an inbound trace header treated as configuration rather than as hostile input.

That is the lesson worth keeping. The plumbing that observes an artificial intelligence (AI) application, the tracing, logging, and evaluation tooling wrapped around the model, has become part of what an attacker can hit. Threat models for these stacks tend to end at the prompt and the model weights. The instrumentation around them rarely gets a second look, and that is precisely where both of these flaws lived.

What to do this week

  • Upgrade. Move to langsmith 0.8.18 or newer. 0.8.18 is already the current release on PyPI, so nothing is holding you back.

  • Drop trace headers at the door. Propagation headers like traceparent, tracestate, and baggage have no business arriving from outside your network. Strip them at the gateway or load balancer before any app server sees them. Almost nobody writes that rule, and it would have neutered both bugs.

  • Prune workspace access. Treat the right to read LangSmith traces as access to sensitive data, not a casual debugging perk, and audit who currently holds it.

  • If you cannot patch yet, follow the maintainers' interim advice and keep TracingMiddleware off any route that takes untrusted traffic.

None of this is clever. It is the ordinary discipline you already apply to inbound headers, finally pointed at a layer people forgot was reachable from the outside. Two tracing bugs in five months say it plainly: in an AI stack, the tools watching your app are a target in their own right.

Topics

Frequently asked questions

What is the LangSmith TracingMiddleware file-read vulnerability?

It is a flaw, tracked as GHSA-f4xh-w4cj-qxq8, in the LangSmith SDK below version 0.8.18. An attacker who can send an HTTP request to a server running its TracingMiddleware can make that server read an arbitrary local file and upload the contents as a trace attachment.

Which LangSmith versions are affected and what is the fix?

All langsmith Python package versions below 0.8.18 are affected. The fix is to upgrade to langsmith 0.8.18 or later, which is the current release on PyPI. Until you can upgrade, keep TracingMiddleware off any path that accepts untrusted HTTP traffic.

Does the attacker need to authenticate?

Triggering the file read needs no authentication; anyone who can reach the server over HTTP can start it. Retrieving the leaked file does require read access to the LangSmith workspace that the traces are sent to, so a low-privilege workspace member or contractor can complete the attack.

Is there a CVE for this LangSmith flaw?

No CVE identifier has been assigned to the file-read flaw. It is tracked by its GitHub advisory ID, GHSA-f4xh-w4cj-qxq8, published on June 19, 2026 and rated 7.7 out of 10. Reference the advisory ID in tickets and scanning rules.

How does this relate to CVE-2026-25528?

CVE-2026-25528 was a separate server-side request forgery bug in the same LangSmith tracing layer, patched in February 2026 in version 0.6.3. Both flaws share a root cause: the tracing code accepted attacker-supplied HTTP headers as trusted input rather than validating them.

How can teams detect or prevent tracing-header attacks?

Strip tracing-propagation headers such as traceparent, tracestate, and baggage at your gateway or load balancer so they never reach application servers from outside your network. Pair that with patching the SDK and reviewing who holds LangSmith workspace trace-read access.

Ready to meet the Guardians?

Deploys fast - agentless for monitoring and cloud, a lightweight agent for deep endpoint security. Just Suriq, standing watch.