Cross-tenant token confusion

A broker sitting between users and a shared backend fails to keep sessions apart, so a token supplied by one caller gets used to serve a different caller's later request, with no attack step beyond timing.

How it works

An MCP (Model Context Protocol) server, or any similar broker, sits between a set of callers and a privileged backend API. Each caller supplies its own credential, for example a Terraform Cloud token, and expects the broker to use that credential only for that caller's own requests. In stateless HTTP mode this depends on the broker assigning a unique session identifier per connection and binding the supplied token to it for the life of that session.

HashiCorp's Terraform MCP Server shipped a version, CVSS 10.0, where the underlying library did not assign unique session identifiers in stateless mode. Requests from different users could be served using whichever token the broker last associated with the shared session state, so one user's Terraform token could be used to satisfy a later request from a completely different user, with neither user doing anything wrong. There is no exploit step here in the conventional sense; a normal, concurrent workload against the broken broker produces the confusion on its own.

Why it works

A broker between an agent and a privileged API is functionally a credential store, and the entire value of that role depends on it never confusing whose credential belongs to whose request. The control assumption that fails is that "stateless" and "must not mix up two callers" are compatible by default. They are not: statelessness removes the persistent session object that would normally anchor a credential to a caller, so unless the broker makes caller identity an explicit, per-request input rather than an artifact of shared state, two concurrent requests can end up sharing a credential neither of them supplied. The API on the receiving end sees a token it recognizes and a request that looks completely legitimate, because it is a real token, just the wrong one.

How to detect it

API calls to a backend that used a caller's credential to act on a resource that caller's own account history shows no prior relationship to.
A broker's request logs showing session identifiers reused or absent across concurrent connections from different source identities.
Backend audit logs where the acting principal and the requesting session do not correlate to the same upstream user across a short time window.

Be honest about the limits: this is a broker implementation bug, not an adversary campaign, so there is no attacker behavior pattern to alert on. Detection depends entirely on the broker emitting session identifiers and on correlating broker-side session logs against backend-side action logs, which most deployments do not do by default. Absent that correlation, the confusion is invisible from either log alone.

How to stop it

Bind every request to an explicit, per-request identity rather than relying on connection-level or shared session state, especially in any stateless HTTP deployment.
Scope brokered tokens tightly so that even a mix-up cannot cross an environment or tenant boundary; a broker that can only ever hold narrowly scoped tokens limits the blast radius of a confusion bug.
Patch and upgrade broker software promptly when a vendor discloses a session-handling flaw; this class of bug is a supply chain risk in the non-human identity layer, not a configuration choice you control directly.
Audit for per-request identity binding in any MCP or similar broker before putting it in front of a privileged API, rather than assuming the framework provides it.
Log and reconcile broker sessions against backend actions so a confusion event is detectable after the fact even without a real-time alert.

Seen in the wild

A CVSS 10.0 bug let one user's Terraform token serve another user's request