Amazon Web Services has fixed a server-side request forgery flaw in its open-source MCP Gateway Registry that could let an authorised user reach services on a deployment's internal network. The flaw, tracked as CVE-2026-125926, affects versions 1.0.3 through 1.34.0 and is fixed in version 1.35.0.

AWS published the issue in security bulletin 2026-180-AWS on 11 November 2026 and rated it Important. The GitHub security advisory for the flaw, GHSA-fc39-fwh3-wv5r, scores it 8.5, rated High under CVSS 3.1. It is classed as CWE-918, improper limitation of a pathname to a restricted directory, in its request-forgery form.

How the flaw works

The MCP Gateway Registry is an open-source registry and gateway for Model Context Protocol servers. It centralises discovery, access control and proxying of registered MCP tool assets, the tools that AI assistants and agents call on to reach outside systems.

The flaw sits in the server registration and update API. The registry did not validate the upstream address of a registered server, so an authenticated user with permission to register or modify a server could point that address at a service on the deployment's internal network. The gateway would then send requests to that destination on the user's behalf and, in some cases, return the responses.

That matters because the gateway sits in a trusted network position. Depending on how the network is configured, reachable targets could include the cloud instance metadata service and the temporary credentials it issues. A registry running with an attached cloud role could therefore leak credentials that let an attacker move into the wider AWS environment.

Who is affected and what to do

Every version from 1.0.3 through 1.34.0 is affected. Version 1.35.0 fixes the flaw by validating upstream addresses when a server is registered or modified. AWS recommends upgrading to the latest version and making sure any forked or derivative code is patched to include the same fix.

AWS also warns that upgrading alone does not clean up damage already done. Version 1.35.0 leaves server configurations stored before the upgrade unchanged, so a poisoned upstream address planted while an affected version was running will survive the patch. Administrators should review the upstream addresses of all registered servers and remove any they did not intend, audit application logs for unexpected registrations or changes, and, if the registry runs with an attached cloud role and the logs cannot rule out abuse, review that role's activity and rotate its credentials.

There is also a version trap to watch. A separate, unrelated issue in the product's external management API was fixed in version 1.25.0, but that release does not fix this flaw. Deployments running 1.25.0 or later therefore remain exposed to the request forgery until they reach 1.35.0.

Workarounds for teams that cannot upgrade yet

For deployments that cannot upgrade immediately, AWS suggests limiting the permission to register and modify servers to trusted accounts, restricting outbound network access from the registry and authentication-server components to the destinations they need, and, on Amazon EC2, requiring IMDSv2 and granting each attached role only the permissions it needs. AWS stresses that these measures limit risk but do not replace the post-upgrade review.

AWS credited external researcher novice-22 for reporting the issue through coordinated disclosure. The bulletin does not report exploitation in the wild, but the flaw is the kind that rewards prompt patching: the gateway is designed to sit between AI agents and internal tools, and a single trusted account with registration rights was enough to turn it into a route inside the network.