The report
On November 6, Agent Router released version 1.2.1 with fixes spanning six separate MCP and AI-gateway defects. The most consequential distinction is architectural: some flaws allowed a request to cross an authorization boundary; others made one namespace or malformed upstream response disrupt shared infrastructure. These were different bugs, not six reports of a single exploit, and the disclosures do not establish customer compromises.
What the patch changes
| Boundary | Vulnerable behavior | Repair in 1.2.1 |
|---|---|---|
| Identity headers | The MCP proxy listened on :9856 and accepted identity headers normally populated by Envoy. A pod-network peer could bypass the verifier if it could connect directly. |
Bind to 127.0.0.1:9856; roll Gateway pods serving MCP routes. |
| MCP session reuse | A session created under a protected route could be resumed on another, weaker route, allowing unverified JWT scope data to reach the original route's tool policy. | Bind each session to its creating MCPRoute; cross-route requests return HTTP 400. |
| Prompt exclusion | prompts/list hid an excluded prompt, but a caller with a valid session and the name could still use prompts/get. |
Apply exclusions to direct retrieval and prompt completion as well as listing. |
| Session seed | Encryption seeds persisted in injected container arguments visible to principals with Pod-read permissions. | Deliver seed material via Secret-backed filter configuration rather than Pod argument strings. |
| OAuth metadata | A namespaced MCPRoute could direct a shared controller to read unbounded metadata. | Cap each metadata response at 1 MiB and try the next known URL when oversized. |
| Provider translation | Null or omitted fields in a successful upstream reply could panic the shared external processor, interrupting unrelated in-flight traffic. | Make affected provider response and tracing paths nil-safe. |
The session and proxy problems are not interchangeable. The route-reuse finding required a caller to establish an initial valid protected session and reach a second route with weaker bearer-token validation. The direct-listener finding required a network path to the internal port but bypassed the frontend that was meant to authenticate headers. The seed flaw required Kubernetes permission to read Pod specifications, rather than direct read access to Secrets. The prompt issue needed a connected route and a known or guessed prompt name; it was not anonymous route access. Advisories, cross-route session, seed storage, prompt access.
The measured failures were conditional
In a controlled Kubernetes test of the metadata issue, a valid 40 MiB JSON response repeatedly exhausted a controller limited to 160 MiB and delayed reconciliation in another namespace for 43 seconds. That is evidence of shared-control-plane failure under the test conditions, not an independently measured production outage. The malformed-response advisory separately documents successful-status AI provider replies with null fields that could terminate the sidecar and interrupt other requests on the same gateway. OAuth advisory, response-handling advisory.
The release guidance calls for upgrading both the CRD and application charts. It says gateways serving MCPRoutes are rolled, open sessions survive if the seed is unchanged, and clients that reuse a session ID across routes must initialize another session. Rotating a seed outside the chart needs controller restart for the new value to take effect. These are deployment details, not an assertion that any unverified installation has already been repaired.
The useful reading of this release is narrower than a broad claim that MCP is insecure. The six findings identify where a gateway implementation treated upstream authentication, a listing filter, shared-controller inputs or a successful HTTP status as sufficient proof for a later decision. Version 1.2.1 adds checks at those specific boundaries. The cited reports do not test every installation mode or prove a zero-risk state.