CVE-2026-125926: AWS mcp-gateway-registry SSRF Lets Authenticated Users Probe Internal Networks

AWS disclosed CVE-2026-125926 on November 11, 2026: authenticated operators on the open-source mcp-gateway-registry could register or edit MCP servers with upstream addresses that turned the gateway into an internal-network client. The fix ships in version 1.35.0. If you run 1.0.3 through 1.34.0, upgrade and manually review every stored upstream URL—the patch does not rewrite old registrations.

mcp-gateway-registry is AWS's registry and proxy for Model Context Protocol servers: discovery, access control, and tool proxying in one place. Teams wire coding agents to it so assistants reach approved MCP tools without ad hoc URLs. The flaw sits in how the registry trusted user-supplied upstream targets, not in MCP message parsing on your laptop.

For broader AWS agent-platform context, explainx.ai covered Agent Registry push sync and CloudTrail wiring separately from this bulletin.

TL;DR

What AWS and GitHub published

AWS security bulletin 2026-180-AWS, published November 11, 2026, classifies the issue as Important (requires attention). GitHub advisory GHSA-fc39-fwh3-wv5r carries the same text and rates severity High on the GitHub scale.

The NVD entry lists CWE-918 (SSRF). Amazon's CVSS 4.0 vector scores 6.3 Medium (CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:N/VA:N/SC:H/SI:L/SA:N). GitHub's CVSS 3.1 vector for the advisory is 8.5 (AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:L/A:N), reflecting changed-scope confidentiality impact when the gateway can reach resources outside its immediate trust boundary.

Core mechanism, quoted in substance from the bulletin:

The registry did not validate the upstream address of a registered server. A user with permission to register or modify a server could set an address that pointed at a service on the deployment's internal network, and the gateway would then send requests to that service. In some cases the gateway returned those responses to the user.

That is classic SSRF with response reflection: the attacker does not merely trigger a blind callback; they may read what the internal service returns, bounded by what the gateway forwards.

Product role

AWS describes mcp-gateway-registry as centralizing discovery, access control, and proxying of registered MCP tool assets. In agent deployments, that usually means:

• Developers register MCP server endpoints the organization approves.
• Clients (IDE assistants, automation jobs, AgentCore-style runtimes) resolve tools through the gateway instead of hard-coding URLs.
• The gateway's network position and IAM role become the effective trust anchor for every proxied tool call.

When registration APIs accept arbitrary upstream hosts, whoever may edit registrations controls where the gateway connects, not just which tools are labeled public.

Attack chain step by step

The bulletin implies the following path; no public exploit code accompanied the disclosure.

1. Obtain credentials on the registry deployment with permission to register a new MCP server or update an existing server's upstream address. AWS does not define the exact RBAC name; treat any role that can change server metadata as in scope.

2. Register or edit a server through the server registration and update API, setting upstream (or equivalent configuration field per your deployment) to a crafted URL the gateway process can reach but the user cannot call directly from their laptop. Examples teams worry about include RFC1918 hosts, loopback services bound on the gateway host, internal Kubernetes service DNS names, and cloud metadata endpoints when outbound policy allows them.

3. Trigger gateway traffic through normal MCP proxy behavior—often by listing tools, invoking a tool, or health-check flows that cause the gateway to contact the registered upstream.

4. Receive reflected content when the gateway returns upstream responses to the authenticated user. That is what elevates impact beyond blind port scanning: HTML error pages, JSON admin APIs, or metadata XML may leak to the attacker account.

5. Optional credential abuse if the gateway runs with an attached cloud role and metadata access is reachable without IMDSv2 enforcement. AWS lists metadata risk as deployment-dependent and asks teams to review role activity and rotate credentials when logs cannot rule out abuse—not because confirmed theft is documented for this CVE.

This is not prompt injection and not a malicious MCP skill on the developer machine. It is infrastructure SSRF in the shared gateway your agents already trust.

Version sequencing: do not stop at 1.25.0

AWS's bulletin includes an easy-to-misread note:

A separate and unrelated issue in this product's external management API was addressed in version 1.25.0. A deployment running 1.25.0 or later carries that fix, but remains affected by the issue described here until it runs version 1.35.0 or later.

Operationally, patch tracking spreadsheets that marked mcp-gateway-registry "current" at 1.30.x may still be vulnerable to CVE-2026-125926. Tie this CVE to 1.35.0, not to the earlier management-API release.

The same November 11 bulletin batch also published CVE-2026-100307 (missing authorization on the external management API enabling privilege escalation to registry administrator). If you have not reviewed that bulletin yet, read it alongside this one—they are different flaws with different minimum versions.

Who is affected

You are not in scope for this CVE if you only run local stdio MCP servers with no shared registry, though unrelated MCP client issues still apply—see the MCP Python SDK SSRF and redirect advisories for client-side $ref fetches.

How to check your deployment

Confirm the running version

Identify how you deploy the registry (container image tag, Helm chart appVersion, git checkout). Compare against:

• Affected: >= 1.0.3 and <= 1.34.0
• Fixed: 1.35.0 and later (release tag)

If you package the app yourself, inspect your build pipeline artifact version rather than guessing from documentation screenshots.

Inventory registration privileges

List IAM or application roles that can:

• Call server registration APIs
• Edit existing server records
• Operate the external management API (separate CVE, but overlapping admin surfaces)

AWS workarounds emphasize limiting registration and modification to trusted accounts until upgrade completes.

Review stored upstream addresses (required after upgrade)

Version 1.35.0 validates upstream addresses on new registration or modification only. The bulletin is explicit that configurations stored before the upgrade are unchanged. Steps:

1. Export or inspect every registered server's upstream URL.
2. Remove or correct destinations you do not recognize—especially link-local, metadata, and private-space hosts you did not intentionally register.
3. Correlate with change tickets; unexplained edits during the vulnerable window warrant incident review.

Review logs

Examine application logs for the period when affected versions ran. Look for:

• New server registrations outside change windows
• Upstream address edits on existing servers
• Unusual tool proxy errors pointing at internal hostnames

Cloud role hygiene

If the registry uses an attached cloud role and log review cannot rule out unexpected activity, AWS advises:

• Review CloudTrail or equivalent role activity
• Rotate role credentials if abuse cannot be excluded
• Enforce IMDSv2 on EC2 and least-privilege policies on attached roles (workarounds, not substitutes for patching)

Workarounds when you cannot patch immediately

From bulletin 2026-180-AWS:

• Restrict who may register or modify servers to tightly scoped break-glass accounts.
• Egress-filter the registry and auth-server components to required destinations only.
• On Amazon EC2, require IMDSv2 and trim attached role permissions to the minimum each component needs.

These reduce blast radius for compromised insider accounts; they do not replace upgrading and reviewing stored upstreams.

What this means if you run AI coding agents

Most developers never install mcp-gateway-registry locally. They add an HTTP MCP endpoint their platform team provides—similar in trust terms to hosted bridges discussed in Pomerado's website-to-MCP launch, except mcp-gateway-registry is typically self-operated infrastructure with your org's IAM footprint.

Concrete actions on the laptop side:

1. Ask operators for the registry version and confirmation that post-upgrade upstream audits finished. If they cannot answer, treat the gateway as unpatched until they can.

2. Read your MCP JSON before agents connect. Know whether tools route through a central gateway versus direct localhost servers. Gateway SSRF does not rewrite your local file, but it changes what remote tool calls can reach.

3. Patch adjacent MCP stacks you do control—Python SDK, TypeScript SDK, and pinned server images—using the triage mindset in CVE volume in 2026: prioritize issues on software you actually run, not every headline CVE.

4. Revisit supply-chain launch patterns (Corelight's uvx drift study) separately. This AWS flaw is server-side; Corelight's work is client-side install drift. Both affect the same MCP session.

5. When testing AWS agent tooling locally, prefer offline emulators with known boundaries where appropriate—see AWS Emulator for local agent testing—but do not confuse an emulator sandbox with patching a production registry.

How Beam handles this

Beam watches local coding agent behavior: MCP and skill configs on your machine, risky tool patterns, and optional PreToolUse denies for Claude Code and Codex. It does not deploy, patch, or egress-filter mcp-gateway-registry on your VPC.

Where overlap exists:

• beam scan --mcp (and related config scans) flag heuristic issues in MCP JSON—unexpected URLs, missing version pins, risky launch patterns—before you connect. That helps you notice a gateway URL you cannot verify, but it cannot detect server-side SSRF on a remote registry you do not operate.
• Workspace enforce mode can deny matched local tool calls when policy is cached; it is hook-based, not a network sandbox, and fail-open when policy is missing.
• Beam's 11-pattern skill scan plus MCP version-pin checks address local supply-chain shapes, not authenticated SSRF in a shared gateway's admin API.

If your organization runs mcp-gateway-registry, Beam complements patching—it does not replace 1.35.0, upstream audits, or IAM review. For a broader MCP review checklist before you add any server, see MCP server security review.

Frequently asked questions

What is CVE-2026-125926?

It is server-side request forgery in the server registration and update API of AWS mcp-gateway-registry before version 1.35.0. An authenticated user with permission to register or modify servers could configure an upstream address that made the gateway send requests to internal services and sometimes read the responses.

Which mcp-gateway-registry versions are affected?

AWS lists impacted versions as greater than or equal to 1.0.3 and less than or equal to 1.34.0. Version 1.35.0 contains the fix. Deployments on 1.25.0 through 1.34.0 remain affected to this SSRF even though 1.25.0 addressed a separate external management API issue.

Do I need authentication to exploit this?

Yes. The bulletin and GHSA-fc39-fwh3-wv5r describe an authenticated remote user who already has permission to register or modify MCP servers in the registry. This is not an unauthenticated internet-wide spray against every gateway.

Does upgrading to 1.35.0 clear old risky upstream addresses?

No. Version 1.35.0 validates upstream addresses on new registration or modification only. Configurations stored before the upgrade are left unchanged. AWS requires reviewing existing upstream URLs, registry logs, and possibly rotating attached cloud role credentials after upgrade.

Could this leak cloud instance metadata credentials?

The advisory states that reachable services depend on the deployment network layout and names the cloud instance metadata service as a concern when the gateway returns responses. AWS does not confirm credential theft or in-the-wild exploitation for this CVE specifically.

What should coding agent users do if their company runs this gateway?

Confirm the registry version with whoever operates it, ask whether post-upgrade upstream audits finished, and treat the gateway URL in your MCP config like any other high-trust bridge. Locally, scan MCP JSON before connecting and avoid pointing agents at gateways you cannot patch or audit.

Related reading

• Corelight uvx MCP study: transitive PyPI drift behind pinned servers (Nov 2026)
• MCP Python SDK: three advisories fixed in 1.30.0 and 2.2.0
• MCP server security review
• Pomerado website-to-MCP: keyless trials and saved logins
• CVE volume in 2026: triage for agent users
• AWS Emulator: local offline testing for coding agents
• Beam MCP security solutions

Primary sources: AWS security bulletin 2026-180-AWS · GHSA-fc39-fwh3-wv5r · NVD CVE-2026-125926 · mcp-gateway-registry release 1.35.0

Version numbers, bulletin text, and advisory severity ratings reflect AWS and GitHub publications as of November 12, 2026. Confirm your deployment's tag and fork lineage before marking remediation complete.