Envoy AI Gateway flaw lets attackers hijack MCP sessions

A vulnerability in Envoy's AI Gateway lets one authenticated user take over another user's Model Context Protocol session, according to a GitHub security advisory published on 19 October 2026. The advisory covers the Go package github.com/envoyproxy/ai-gateway and concerns the gateway's MCP proxy, the component that sits between clients and backend MCP servers.

MCP is the protocol agents use to call tools and read resources from external servers. Envoy AI Gateway mints a session identifier for each client and, according to the advisory, deliberately embeds the authenticated caller's JWT sub claim inside it as an anti-hijacking discriminator. The advisory says this follows the Model Context Protocol specification's documented guidance on session hijacking.

The problem is that the check is never performed. The advisory states that the session-resume path never compares the embedded subject against the identity of the caller presenting the session ID. A code comment at the parsing site, quoted in the advisory, says the subject "is retained inside the encrypted session ID for anti-hijacking purposes but is not needed during parsing". In practice the value is discarded, never returned and never compared. The advisory adds that the resume function is not even passed the current request's authenticated subject, so there would be nothing to compare it against. The subject is extracted exactly once, at session creation.

The result, the advisory says, is that anyone who obtains another user's Mcp-Session-Id value can resume that user's session against the backend MCP servers bound to the route. That includes reading conversation and tool-call state, and invoking further JSON-RPC methods such as tools/call and resources/read in the context of the other user's already-initialised backend session. On a multi-tenant deployment, the advisory says, this crosses exactly the trust boundary the subject-embedding was meant to protect.

A second issue makes the first considerably worse. The advisory says the official Helm chart ships a literal, publicly known default seed, the string default-insecure-seed, for the key that encrypts session IDs. The same string is hard-coded as the fallback in the controller and extproc binaries when the command-line flag is omitted. Because session IDs are built from a salt, a nonce and ciphertext, the advisory says knowing the seed and the default PBKDF2 iteration count is enough to derive the AES-GCM key, decrypt observed session IDs and encrypt new ones for any chosen subject and backend session. In other words, an attacker running against a default install would not need to capture a victim's session ID at all; they could forge one.

The advisory sets out a step-by-step reproduction using an MCP route with a JWT security policy attached, but notes the work was done at code level and was not run against a live cluster. It says the finding came from the Aeon vuln-scanner through an agentic dataflow review of the MCP proxy, followed by manual adversarial verification against a specific commit on the project's main branch.

The advisory recommends two fixes: thread the current request's subject through to the session-resume logic and reject resumption with a 401 or 403 when the subjects do not match; and change the Helm chart so the encryption seed is generated randomly per install rather than shipped as a fixed string, or at minimum fail startup when the insecure default is in use outside development mode. The record of the issue lists its status as reported.