The report
In Microsoft MCP Gateway, Kubernetes correctly returned a conflict when a proposed object name already existed. The application could still treat the corresponding resource as owned by the caller. That mismatch gave an authenticated user a route to other tenants' tool workloads and potentially the built-in tool gateway itself.
A database ownership record and a real workload diverged
The gateway stored tool and adapter metadata separately but deployed their workloads into the same Kubernetes namespace. A caller could choose a name already used by another resource type. Kubernetes rejected the duplicate with 409 Conflict, yet the gateway created a record owned by the caller. Subsequent status, log, update, delete and routing operations used the object name without reconciling the stored owner with the actual Kubernetes resource.
The particularly sensitive name was toolgateway, used by the built-in service. Under the conditions detailed in the Microsoft advisory, replacing its container image could preserve the service account and secret environment, including authority needed to manage workloads in that namespace. The attacker needed authenticated permission to create an MCP tool or adapter; this was not anonymous Kubernetes cluster access. The Case dossier separates cross-user log access from the more privileged built-in-gateway replacement path.
Microsoft fixed the behavior in version 1.0.0, with the source correction dated October 14 and advisory publication October 16. It reserves the built-in name, prevents collisions across tool and adapter types and verifies real workload ownership before effects. No actual hostile production tenant is reported.
There is a difficult recovery detail. The fix prevents subsequent operations from using mismatched records, but it cannot automatically restore a container image previously replaced or invalidate a copied gateway secret. An operator with historical exposure must inspect the running workload and its service-account and secret bindings, then redeploy and rotate as indicated. An application-level ownership table is not authoritative merely because its records have unique internal IDs.