CVE-2026-16326

A critical token isolation failure in an MCP server's 'stateless mode' allowed one client's Consul token to persist and be exposed to subsequent requests from other clients. This is not a minor credential leak—it is a credential harvesting mechanism baked into the architecture. When client A's token survives into client B's request context, a single exploitation doesn't compromise one credential; it poisons the authentication layer for every client sharing that server instance. Check whether you're running versions 0.1.0 through 0.1.3 of the affected MCP server. The fix shipped in 0.1.4, but the 'stateless mode' label creates a dangerous assumption: operators may believe nothing persists, nothing needs rotation, and nothing requires audit. That assumption is exactly what the vulnerability exploits. Assume exposure. Rotate every Consul token that has ever touched a 0.1.0-0.1.3 instance—not just the tokens you think were used during a compromise, because the harvesting mechanism means any token could have been captured. If you're running stateless mode because it seemed simpler or safer, verify the actual isolation behavior in your deployment: test whether tokens from one request context appear in another. The architectural label promised isolation; the implementation did not deliver it. The CVSS 10 rating with low EPSS suggests either the MCP server ecosystem is small or exploitability in typical deployments is more constrained than the severity implies. But low EPSS for critical CVEs often signals that the vulnerable pattern—claiming statelessness without behavioral isolation verification—is distributed across similar implementations. Your adjacent tools may carry the same flaw under different labels.

Reviewed through automated stages and approved by a human before publication.