3366 Members
Join Permit's SlackTL;DR: CVE-2026-109492 is an authorization bypass through a user-controlled key (CWE-639) in Microsoft's open-source MCP Gateway, rated CVSS 8.8 by Microsoft and fixed in 1.0.0. The gateway named Kubernetes objects after user-chosen resource names in one namespace, so a user who could create adapters or tools could claim a name that already belonged to someone else, or to the built-in tool gateway, and then act on that workload. MCP gateway security has two layers: the control plane (who can create, rename, own and change adapters and tools) and the data plane (whether this caller may invoke this tool, with these arguments, right now). Both need authorization checks that do not trust names a user picked.
Most conversations about MCP gateway security focus on the tool call: is this agent allowed to run delete_repo for this user? That question matters, and we cover it below. CVE-2026-109492 is a reminder that the gateway is also a multi-tenant application with its own management API, and that API needs the same authorization discipline as any SaaS product.
Microsoft disclosed the issue through the project's GitHub security advisory and the CVE record, shipped the fix, and documented how to check for past abuse. The advisory is worth reading for anyone building or running a gateway, and this post walks through what it teaches.
Here are the facts from the NVD record, Microsoft's Security Update Guide entry and the project's GitHub security advisory GHSA-frpg-5vp2-p974:
| Product | Microsoft MCP Gateway (open source, runs on Kubernetes) |
| Weakness | CWE-639, Authorization Bypass Through User-Controlled Key. The GitHub advisory also lists CWE-706 (incorrectly resolved name or reference) and CWE-862 (missing authorization). |
| Severity | CVSS 3.1 base score 8.8, scored by Microsoft (AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H). Microsoft rates it Important, with Elevation of Privilege impact. |
| Who can exploit it | Any authenticated user who can create adapters or tools. No administrator role is required. |
| Affected | Versions before 1.0.0, which covers builds from main before commit f57c4f0 (October 14, 2026) that include tool management, and latest images published before that date |
| Fixed | 1.0.0 (tag v1.0.0, commit f57c4f0) |
| Disclosed | GitHub advisory on October 16, 2026; CVE published November 10, 2026 |
| Exploited | Microsoft's entry lists it as not exploited |
The gateway deploys each adapter and each tool as a Kubernetes StatefulSet and Service named after the resource, in the same namespace as its built-in tool gateway. According to the advisory, three things combined:
toolgateway, was accepted, and so were names already used by the other resource type.409 Conflict because a StatefulSet or Service with that name already existed, the gateway ignored the conflict and saved a new record owned by the caller.The caller passed the authorization check on their own record, and the gateway then acted on a workload they never owned.
The advisory describes two outcomes:
toolgateway, then update it to swap the tool gateway's container image for another image from the gateway's configured registry. The replacement kept the tool gateway's service account (which can manage StatefulSets, Services and Pods in the namespace), its secret environment variables, including the gateway's shared secret, and its traffic. Deleting that adapter deleted the tool gateway.In 1.0.0, toolgateway is a reserved name, adapter and tool names must be unique across both types, and creation fails if a Kubernetes object with the generated name already exists. Update, delete, status, logs and routing first verify that the workload belongs to that resource's type and name, and updates and deletes are conditional on the verified object.
If you run the project, the advisory's guidance is to update to 1.0.0 or later and redeploy. Until then, limit access to the management API to trusted users. To check for past abuse, look for an adapter named toolgateway or a name that exists as both an adapter and a tool, and confirm the toolgateway StatefulSet runs your expected image with no unexpected environment variables. If it doesn't, the advisory says to redeploy it from your manifest and rotate the gateway secret, plus the Redis connection string if you use one. Updating does not undo changes already made to a workload.
CWE-639 describes a system that checks whether you may act on a record, while the record is identified by a value you supplied. Classic examples are changing ?account_id=123 to 124 in a URL. Here the key was the resource name, and it reached a second system (Kubernetes) that had its own namespace of names and no idea which tenant a name belonged to.
That second hop is what makes gateways interesting. An MCP gateway usually sits on top of something else that has global names: Kubernetes objects, DNS records, container image tags, secret names, queue names, upstream OAuth client registrations. Every time the gateway turns a tenant's input into one of those names, it creates a place where two tenants, or a tenant and the platform itself, can collide.
The general rule is simple to state: the authorization decision has to be about the object that will actually be touched, and it can't rely on a name the caller chose.
Shortly after the CVE-2026-109492 record went out, AWS published Security Bulletin 2026-180-AWS for CVE-2026-125926 (GHSA-fc39-fwh3-wv5r), a server-side request forgery in the server registration and update API of the open-source mcp-gateway-registry project. AWS credits the external researcher novice-22 for reporting it through coordinated disclosure.
Per the bulletin, an authenticated user with permission to register or modify a server could set that server's upstream address to a service on the deployment's internal network. The gateway then sent requests there, and in some cases returned the responses to the user. Versions 1.0.3 through 1.34.0 are affected, and 1.35.0 fixes it. A separate management API bug was fixed in 1.25.0, so being on 1.25.0 or later does not mean you are covered here.
The bug class differs from CVE-2026-109492. The control-plane lesson is similar. Registering a server is a privileged action, because the upstream address decides where the gateway sends traffic from inside your network. Three things follow from the bulletin:
Both CVEs come down to who is allowed to change gateway config and what the gateway does with values they supply.
The control plane is everything an operator or tenant does to configure the gateway: registering MCP servers or adapters, defining tools, setting credentials, changing images or routes. These checks come straight out of the bug class above.
Creating an adapter is a privileged action. It decides what code runs inside your cluster and what traffic it receives. Treat it as a permission on its own (adapter:create within a tenant), separate from permission to call tools. Renaming deserves its own check too, because a rename is effectively a new claim on a name. Ownership should be recorded explicitly, and transferring ownership should be an authorized action, never a side effect of creating something with a matching name.
The cleanest fix is to stop deriving infrastructure object identities from user input. Generate an internal ID for each resource and name the Kubernetes objects after that ID, keeping the user's display name as a label. If you must derive names, scope them by tenant (a per-tenant prefix or namespace), enforce uniqueness across every resource type that shares the same backing namespace, and fail creation when the target object already exists. A 409 Conflict from the infrastructure is a security signal. Never swallow it.
A shared namespace means every tenant's workloads live in one pool of names, and isolation depends entirely on application logic getting every check right. Stronger options include a namespace per tenant, network policies between tenant workloads, and separate service accounts per tenant so one compromised workload can't manage another's. Whatever the boundary, the gateway's own authorization model should carry the tenant in every decision, so that "may user X update adapter Y" is always evaluated as "may user X in tenant T update adapter Y in tenant T".
Check ownership of the actual backing object on every write and every sensitive read, not only the database record. Logs and status count as reads of another tenant's data. The 1.0.0 fix verifies that the workload belongs to the resource's type and name and makes updates and deletes conditional on the verified object.
The built-in tool gateway held a service account that could manage StatefulSets, Services and Pods, plus the shared secret. Platform components like that should never be addressable through the tenant API at all. Reserve their names, run them where tenant workloads can't be created, and give them the narrowest service account that works. If an image can be changed through an API, that API needs an admin-only permission and an audit record.
Microsoft's advisory includes a section on checking for past abuse, and every step in it relies on being able to see which adapters exist, which names collided and what image a workload runs. Log who created, renamed, updated or deleted each adapter or tool, in which tenant, and what changed. Compliance reviewers ask for this log too.
Once the control plane is sound, the gateway still has to decide every tool call. Authentication tells you who started the session. It doesn't tell you whether this agent, acting for this person, should run this tool with these arguments.
The checks that matter here:
read_issue and deny delete_repo for the same user, or allow a query on one project and deny it on another. Evaluate it on every call, outside the model.If you want depth on any of these, we've covered the confused deputy problem in AI agents and MCP, MCP OAuth 2.1 with PKCE and resource metadata, enterprise-managed authorization and tenant isolation for MCP servers, and why MCP database servers need fail-closed authorization.
A common question is whether adding an MCP gateway "gives you MCP security". It gives you a place to enforce it. A gateway that only proxies traffic and authenticates sessions moves the problem without solving it, and as these CVEs show, the gateway's own management plane becomes part of your attack surface. The difference between a proxy and a gateway that enforces policy is covered in MCP Proxy vs MCP Gateway: What's the Difference?.
MCP security is the full set of controls: identity for humans and agents, control-plane authorization, per-tool authorization, credential handling, isolation of workloads, and audit. A gateway is one enforcement point for those controls. Your APIs, applications and databases are others.
Use these questions on any MCP gateway, open source or commercial, self-hosted or managed.
Control plane
Data plane
Operations
Permit MCP Gateway focuses on the data-plane controls in this article: checking tool calls with Permit before they reach MCP servers, classifying tools by risk and denying by default, showing users which tools an agent can call before they consent, keeping real upstream credentials vaulted in the gateway, and writing calls to an audit log. Use the checklist above on it the same way you would on any gateway.
An authorization bypass through a user-controlled key (CWE-639) in Microsoft's open-source MCP Gateway. Microsoft scored it CVSS 8.8. Because the gateway named Kubernetes objects after user-chosen names in a shared namespace, a user allowed to create adapters or tools could take over another user's workload or the built-in tool gateway.
Versions before 1.0.0, including builds from main before commit f57c4f0 and latest images published before October 14, 2026. Update to 1.0.0 or later and redeploy. Until you can, the advisory recommends limiting management API access to trusted users.
Microsoft's Security Update Guide lists it as not exploited. The GitHub advisory explains how to check a deployment for signs of past abuse.
A server-side request forgery in the server registration and update API of mcp-gateway-registry, disclosed by AWS in Security Bulletin 2026-180-AWS. A user allowed to register or edit a server could point its upstream address at internal services. Versions 1.0.3 through 1.34.0 are affected and 1.35.0 fixes it. After upgrading, AWS asks operators to review stored upstream addresses and logs, and rotate the attached role's credentials if needed.
The set of authorization, isolation and audit controls that protect both the gateway's management plane (who can register and change servers, adapters and tools) and its data plane (whether each tool call is allowed for this user and agent).
Exportable audit trails for control-plane changes and tool-call decisions, identity tied to your IdP, per-tool and per-argument policy, consent records, tenant isolation, evidence retention and a published vulnerability disclosure process. Those are the records an auditor will ask to see first.
Co-Founder / CEO at Permit.io
