GHSA-953H-535J-JG2V

The MCP proxy's client-facing session ID embeds the authenticated caller's
subject (JWT sub claim) specifically as an anti-hijacking discriminator ,
matching the Model Context Protocol specification's documented session-hijacking
guidance (https://modelcontextprotocol.io/specification/2025-06-18/basic/security_best_practices#session-hijacking).
However, the session-resume path never checks that discriminator against the
current caller's identity, so any client that obtains a session ID (its own or
another user's) can resume that session and act with it, including on
routes with per-user backend sessions. This is aggravated by the official
Helm chart shipping a literal, publicly known default seed
("default-insecure-seed") for the key that encrypts these session IDs.

Location

• internal/mcpproxy/session.go, clientToGatewaySessionID.backendSessionIDs()
  (around line 707-765): parses {routeName}@{subject}@{backends} and returns
  only (perBackendSessionIDs, route, error). The comment at the subject-parsing
  site reads: "The subject ... is retained inside the encrypted session ID for
  anti-hijacking purposes but is not needed during parsing.", the subject is
  discarded, never returned, never compared.
• internal/mcpproxy/mcpproxy.go, sessionFromID(id, lastEvent) (around line
  282-323): resumes a session purely from the decrypted blob; it is never passed
  the current request's authenticated subject, so there is nothing to compare
  against even if backendSessionIDs() did return it.
• internal/mcpproxy/legacy.go, extractSubject(r) (around line 1549-1562) is
  called exactly once, only at session creation (handleInitializeRequest ->
  newSession, line ~307/484/491) to embed the subject when the session ID is
  minted. All three session-resume call sites (serveGET/servePOST/serverDELETE
  paths, lines ~133, 167, 216) call sessionFromID with no subject argument at all.
• internal/mcpproxy/mcpproxy.go line 259 (clientToGatewaySessionIDFromEntries)
  is where the subject is embedded at creation, confirming the intended design.
• Aggravating factor: manifests/charts/ai-gateway-helm/values.yaml line 297
  ships seed: "default-insecure-seed" as the out-of-the-box value for
  controller.mcp.sessionEncryption.seed, which templates/deployment.yaml
  passes straight to --mcpSessionEncryptionSeed (also literally defaulted to
  "default-insecure-seed" in cmd/controller/main.go and
  cmd/extproc/mainlib/main.go when the flag is omitted entirely). Session IDs
  are salt || nonce || ciphertext (see internal/mcpproxy/crypto.go), so
  knowing the seed and the (also-defaulted) PBKDF2 iteration count is sufficient
  to derive the AES-GCM key and both decrypt observed session IDs and encrypt
  new ones for an arbitrary chosen subject/backend-session combination.

Reproduction (code-level, not run against a live cluster)

1. Deploy Envoy AI Gateway with an MCPRoute that has an OAuth/JWT
   SecurityPolicy attached (so internalapi.MCPSubjectHeader is populated)
   and at least one backend MCP server, using the Helm chart's default
   values.yaml (controller.mcp.sessionEncryption.seed left at
   "default-insecure-seed").
2. User A authenticates with a valid JWT (sub: user-a) and sends an
   initialize JSON-RPC request to the route. The gateway creates backend
   session(s) and returns Mcp-Session-Id: <encrypted-blob-A>, whose plaintext
   is {route}@user-a@{backend}:{base64(sessionID)}:{capHex}.
3. Attacker (any other authenticated user, or, since the seed is public and
   default, even without ever having a legitimate session at all) constructs
   {route}@user-a@{backend}:{base64(<any-or-known-backend-session-id>)}:fff,
   derives the AES-GCM key via PBKDF2(sha256, "default-insecure-seed",
   salt, 100000, 32) for a salt of their choosing, and encrypts it themselves
   to produce a session ID that decrypts to the same structure sessionFromID
   expects.
4. Attacker sends a subsequent JSON-RPC request (e.g. tools/call) to the same
   route with header Mcp-Session-Id: <forged-or-captured-blob-A>. The gateway
   decrypts it, extracts perBackendSessionIDs for backend, and forwards the
   attacker's call using that backend session, with no comparison to the
   attacker's own JWT subject at any point in sessionFromID /
   backendSessionIDs().

Detected by

Aeon vuln-scanner, agentic dataflow review (internal/mcpproxy entrypoint,
Envoy AI Gateway data-plane MCP proxy), followed by manual adversarial
verification against the exact HEAD commit of main
(472da7db7984f769c9a77671d12c0354e75fc3ba, confirmed to match
repos/theagentrouter/agent-router/commits/main at time of report).
Dependency-CVE findings from this scan (osv-scanner, go.mod/package-lock.json)
are not included here, they are all already covered by open Dependabot PRs
(#2555, #2643, #2672, #2497, #2615) and are omitted to avoid duplicate filings.