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, andbaggagehave 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
TracingMiddlewareoff 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.