Envoy was supposed to be the only sender to the MCP proxy, yet a controller-generated argument bound its listener to the pod network. A neighboring workload with TCP reachability could send its own subject, route and backend headers. In configurations with gateway-injected backend credentials, that route could reach MCP tools without passing the…
Inspect the ClaimsCase · DiggingBeagle record
Direct MCP proxy listener bypassed Agent Router authentication headers
A proxy listening on all interfaces trusted identity values normally authenticated by Envoy.
Public disclosure: Nov 6, 2026
Scope
Affected Agent Router MCP gateway configurations using the extproc listener before the 1.2.1 repair. The advisory lists affected versions below 1.2.0 while also describing vulnerable 1.2.0 source; keep that inconsistency visible.
Assessment profile
Assessment method- Setting
- research demonstration
- Exploitation
- demonstrated
- Evidence
- Grade B
- Remediation
- patch available
- AI role
- AGAINST AI
Basis and provenance
The exposed pod listener and trusted-header assumptions are traced in first-party advisory code and configuration; the 1.2.1 release closes loopback reachability. Internet-wide exposure is not shown. An impact band remains unassigned because the available evidence does not establish a comparable severity score or verified numerical loss for this assessment.
Assessed Nov 8, 2026 using diggingbeagle.assessment/1.
Evidence basis: CLM-AGENTROUTER-MCP-TRUSTED-HEADER-01 · Agent Router MCP proxy trusted header bypass · Agent Router version 1.2.1 release
At a glance
A trusted header is authentication only when every path to its consumer is forced through the component that verifies and rewrites it.
Read the implicationsThis is a network-adjacent attack path. A peer still needs access to the pod port; the advisory does not establish public internet exposure, a customer compromise or access through a properly restricted NetworkPolicy.
Limits and uncertaintyFull account
Envoy was supposed to be the only sender to the MCP proxy, yet a controller-generated argument bound its listener to the pod network. A neighboring workload with TCP reachability could send its own subject, route and backend headers. In configurations with gateway-injected backend credentials, that route could reach MCP tools without passing the authenticated frontend.
This is a network-adjacent attack path. A peer still needs access to the pod port; the advisory does not establish public internet exposure, a customer compromise or access through a properly restricted NetworkPolicy.
Envoy was the component that authenticated the caller and injected MCP subject, route and backend headers. The extproc listener accepted those values from another network path because it bound port 9856 on all interfaces rather than loopback. A peer able to reach the Pod port could claim an authenticated identity without traversing Envoy. The advisory's affected-version metadata conflicts with its discussion of vulnerable 1.2.0 code; the repair release is 1.2.1, and the conflict must remain explicit in any affected-version statement.
Mechanism and trust boundary
- 01
Reach the extproc pod port 9856 from a separate workload.
- 02
Supply spoofed trusted MCP identity and route headers directly to the proxy.
- 03
Invoke a configured backend without the Envoy inbound SecurityPolicy.
Claims & evidence
CLM-AGENTROUTER-MCP-TRUSTED-HEADER-01The Agent Router extproc MCP proxy bound TCP port 9856 on all interfaces and accepted caller-supplied route and subject headers without the Envoy frontend authentication filters.supported
Basis: reported finding
- supportsAgent Router MCP proxy trusted header bypassprimary disclosure
Summary; How the proxy is told to listen; Why the exposure matters
Implications
A trusted header is authentication only when every path to its consumer is forced through the component that verifies and rewrites it.
Controls and mitigations
- Deploy Agent Router 1.2.1, bind the extproc MCP listener to 127.0.0.1, and test direct Pod-IP reachability from a distinct namespace.
- Keep Kubernetes network policy and frontend header scrubbing as separate defense layers; never treat reachable client-supplied identity headers as authenticated.
Unknowns and contradictions
- This is a network-adjacent attack path. A peer still needs access to the pod port; the advisory does not establish public internet exposure, a customer compromise or access through a properly restricted NetworkPolicy.
Sources and citation
Material revision history
- Nov 8, 2026 · Canonical change recorded · new in release · revision 229