MCP Gateway Authentication Bypass via Header Injection and Hardcoded Router Key

Vulnerability Description

The MCP router's initialize code path contains a critical authentication bypass flaw. When a request includes the mcp-init-host header, the gateway JWT session validator is entirely circumvented. The vulnerability combines two weaknesses: (1) a trivial shared-secret check using the router-key header as the sole gating mechanism, and (2) unrestricted rewriting of the upstream :authority header to attacker-controlled values. The router-key itself is cryptographically weak—either a hardcoded default string (secret-api-key) in the codebase or a SHA-256 truncation of a non-secret Kubernetes resource UID visible to any user with get permissions on MCPGatewayExtension objects.

PoC Significance

This advisory describes a path-traversal of trust boundaries rather than a traditional network exploit. The PoC proves that an unauthenticated caller can craft HTTP requests with two headers (mcp-init-host and router-key) to completely bypass the broker's signed capability filter and the gateway's session model. The attack is reliable because: (1) no cryptographic validation is required, (2) the router-key can be derived from cluster metadata or discovered via enumeration, and (3) the injection point (initialize method) is reachable without prior authentication. Preconditions are minimal: the attacker needs network access to the gateway and knowledge or guessing of the router-key value.

Detection Guidance

Log Indicators:

• Requests carrying both mcp-init-host and router-key headers originating from unauthenticated sources
• HTTP requests where the :authority header is rewritten to an unexpected or external domain (e.g., api.githubcopilot.com)
• Calls to the initialize method bypassing normal JWT validation logs
• Requests to the router that lack corresponding authenticated session tokens
• Access patterns to the MCPGatewayExtension resource showing repeated get operations (reconnaissance for router-key derivation)

Signature approach: Monitor for requests matching the regex pattern Header: mcp-init-host: .+ combined with Header: router-key: [a-f0-9]{64}|secret-api-key on the initialize path.

Mitigation Steps

1. Immediate: Rotate the router-key value and replace any hardcoded secret-api-key default with a cryptographically random secret stored in sealed cluster secrets (not in argv or environment variables).
2. Short-term: Disable the mcp-init-host header path entirely if not in use; require JWT session validation on ALL request paths with no exceptions.
3. Medium-term: Implement cryptographic request signing (HMAC-SHA256 over request body and headers) instead of simple header checks. Restrict MCPGatewayExtension resource access via RBAC to prevent non-operators from reading the router-key.
4. Long-term: Refactor the initialize method to require authenticated caller identity and integrate with the broker's capability filter before rewriting authority headers.
5. Configuration: Audit all gateway configurations to identify any external backend services (e.g., api.githubcopilot.com) that could be targeted via authority injection.

Risk Assessment

Likelihood of exploitation in the wild: HIGH. The attack surface is easily discoverable—attackers can probe for the mcp-init-host header behavior without special tools. The hardcoded fallback key (secret-api-key) makes exploitation trivial for any attacker without cluster access; derived keys are obtainable via Kubernetes RBAC misconfiguration or public cluster information. Threat actor interest: CRITICAL. This bypass grants direct access to backend APIs (including GitHub Copilot endpoints) and external services, potentially enabling data exfiltration, service compromise, or lateral movement. The vulnerability requires no payload delivery or exploitation complexity—header crafting alone is sufficient.