AWS has disclosed and fixed a server-side request forgery (SSRF) vulnerability in mcp-gateway-registry, its open-source registry and gateway for Model Context Protocol (MCP) servers. The flaw, tracked as CVE-2026-125926, affects versions 1.0.3 through 1.34.0 of the project and was publicly disclosed on November 11, 2026 alongside the release of a fixed version, 1.35.0.

The mcp-gateway-registry project is designed to bring server discovery, access control and tool proxying for MCP servers into a single managed point, which is increasingly how organizations are standing up AI agent tooling internally. That centralizing role is precisely what made this bug worth taking seriously: a flaw in the gateway doesn’t just affect one connection, it affects everything routed through it.

A Trusted User Can Redirect Where the Gateway Connects

The vulnerability lives in how the registry validates the upstream address a user supplies when registering a new MCP server or editing an existing entry. That validation step didn’t adequately constrain where the gateway was allowed to point. Critically, this isn’t an attack any random visitor can pull off — it requires an attacker who already holds a valid account with permission to register or modify servers in the registry.

Given that access, though, the attacker can set a crafted upstream address and get the gateway to issue requests to services sitting inside the deployment’s internal network — services the attacker could not otherwise reach directly. In some cases, the gateway doesn’t just make the request; it returns the response back to the attacker, effectively turning the gateway into a proxy for reconnaissance against internal infrastructure.

Why Cloud Credentials Are Part of the Conversation

The risk escalates further when the gateway itself runs with an attached cloud IAM role, as many AWS-hosted services do. SSRF bugs have a well-documented history of being used to reach cloud metadata services and extract temporary role credentials when metadata endpoints aren’t properly locked down. AWS’s own security bulletin for this issue stops short of confirming that credential theft or active exploitation actually occurred through CVE-2026-125926, but the structural risk is the same pattern security teams have seen in other SSRF cases targeting cloud metadata access.

AWS credited independent researcher novice-22 with reporting the flaw through coordinated disclosure.

The Fix Doesn’t Retroactively Clean Up Existing Configurations

Version 1.35.0 adds validation of upstream addresses at the point of server registration and modification going forward — but it does not automatically revisit or correct server entries that were already stored before the upgrade. That leaves a manual step for administrators:

• Review all existing upstream server addresses after upgrading and remove or correct any destination that wasn’t intentionally configured.
• Check application logs covering the period when an affected version was running for unexpected server registrations or address changes.
• If the registry ran with an attached cloud role and logs can’t rule out suspicious activity during that window, rotate that role’s credentials and review its recent activity.

AWS also flagged that a separate, unrelated flaw in the project’s external management API was fixed earlier, in version 1.25.0 — but that update does not address CVE-2026-125926, so any deployment running versions 1.25.0 through 1.34.0 remains exposed until it’s brought up to 1.35.0. Forked or otherwise derived copies of the project need the same fix applied manually.

Mitigations for Teams That Can’t Patch Immediately

For organizations that can’t upgrade right away, AWS recommends limiting server registration and editing permissions to a small set of trusted accounts, restricting outbound connections from the registry and auth-server components, enforcing IMDSv2 on EC2 instances to blunt metadata-based credential theft, and trimming the permissions attached to the registry’s role to the minimum needed. None of these substitute for upgrading to 1.35.0 and auditing existing configurations, but they narrow the window of exposure while that work is underway. As MCP-based tooling becomes a more common fixture in enterprise AI deployments, this disclosure is a reminder that the infrastructure gluing those tools together deserves the same scrutiny as any other internet-facing gateway.