al-ice.ai

Admin by Import, SSRF by Registration: Two High-Severity Flaws in AWS's MCP Gateway Registry

Agent & Supply Chain Security by al-ice.ai Editorial

On 11 November 2026 AWS published two Important security bulletins (2026-179-AWS at 12:30 PM PST, 2026-180-AWS at 1:00 PM PST) for mcp-gateway-registry, its open-source registry and gateway for Model Context Protocol servers that centralizes discovery, access control, and proxying of registered MCP tool assets. The pair is worth reading together: CVE-2026-100307 (GHSA-rxf3-qgpv-wxvr, CVSS 3.1 8.8 High) lets an authenticated low-privileged user self-grant registry-administrator scope through a crafted group-import request, and CVE-2026-125926 (GHSA-fc39-fwh3-wv5r, CVSS 3.1 8.5 High) lets an authenticated user with server register/modify permission point the gateway at internal-network services — including cloud instance-metadata endpoints — and in some cases read the responses back. The first flaw hands out the exact permission the second flaw needs. Both fixes also share an uncomfortable property: upgrading alone does not remove what an attacker already planted.

The privilege escalation: authentication without authorization

CVE-2026-100307 is a missing-authorization issue in the product's external management API. Per the bulletin, the /api/servers/* management endpoints authenticated the caller but performed no role-based or permission-based authorization. An authenticated low-privileged remote user could submit a crafted group-import request to POST /api/servers/groups/import mapping their own identity-provider group to the registry administrator scope. Because administrator status is derived per request, the escalation took effect on the caller's next request with no re-authentication — granting administrative control over every registered gateway asset, including registry-stored server credentials and custom headers that are decrypted on read through administrator-reachable routes, plus the access-control configuration itself.

Impacted versions are >= 1.0.9 and <= 1.24.7; the fix shipped in version 1.25.0, released 27 June 2026 — meaning the patch predates disclosure by over four months under coordinated disclosure with external researcher novice-22, credited in both bulletins. NVD lists the CVE as Received.

The post-upgrade section is the part operators most often skip, and here it is load-bearing. Version 1.25.0 enforces authorization on the write path, but it does not modify group definitions written before the upgrade and does not invalidate credentials read before it — a privileged group mapping created through the affected endpoints continues to confer administrator access after the upgrade. AWS asks operators who ran an affected version to: inspect the mcp_scopes DocumentDB collection for group_mappings entries pointing at mcp-registry-admin (or another privileged scope) and ui_permissions grants of mutating actions to all, removing anything no administrator created; search HTTP logs for POST /api/servers/groups/import from non-administrator accounts plus the sibling group routes and server-mutation routes, correlating follow-on /api/servers/* requests; rotate registry-managed credentials at their source systems where logs are unavailable or incomplete; and review registered assets for unintended modification — including any upstream URL changed to a different host, which is exactly the foothold the second CVE weaponizes.

The SSRF: your gateway, their upstream address

CVE-2026-125926 sits in how the registry validates the upstream address of a registered server — it didn't. An authenticated user with permission to register or modify a server could configure an upstream pointing at a service on the deployment's internal network, and the gateway would send requests there; in some cases the gateway returned those responses to the user. NVD's description adds the cloud dimension explicitly: crafted requests could reach internal network services and cloud instance metadata endpoints, with responses readable. Impacted versions are >= v1.0.3 and <= 1.34.0; fixed in 1.35.0 (released 29 October 2026 per the GitHub release record; the GHSA was published 11 November 2026).

AWS's own version-sequencing note ties the pair together: a deployment running 1.25.0 or later carries the privesc fix but remains affected by the SSRF until it reaches 1.35.0 — and conversely anything still on <= 1.24.7 carries both. And 1.35.0 validates upstream addresses only at registration/modification time; server configurations stored before the upgrade are left unchanged. Post-upgrade actions: review every registered server's upstream address and correct or remove anything unintended; review application logs from the affected-version window for unexpected registrations and changes; and if the registry runs with an attached cloud role and the log review cannot rule out unexpected activity, review that role's activity and rotate its credentials. Interim mitigations for deployments that cannot upgrade yet: restrict register/modify to trusted accounts, restrict outbound network access from the registry and auth-server components to required destinations, and on EC2 require IMDSv2 with least-privilege roles.

Why this pair matters beyond one product

Three properties generalize. First, the privesc-to-SSRF shape is a privilege-boundary composition failure: each endpoint looks reasonable alone, but group import confers the permission that makes server registration dangerous. Second, both fixes are write-path-only — the malicious state (a group mapping, a poisoned upstream URL) survives the upgrade, so patching without the audit steps leaves the backdoor in place. Third, the metadata angle converts an MCP control-plane flaw into a cloud-credential incident: a gateway that proxies tool traffic is, by construction, the ideal SSRF launch point, because it already holds network position plus stored credentials.

This is the third server-side flaw disclosed in this codebase in four months. Our July briefing covered CVE-2026-14471, a SQL injection in the same registry exposing API key material — linked, not restated. That count in one MCP control plane in one half-year is a pattern, not a streak: it sits alongside the unpinned-config census, MCPhantom's training-data poisoning, and the Corelight dependency-drift findings as evidence that the MCP layer's management surfaces — not just its tool transports — are where the access lives. The cloud-credential thread connects to our Qubole cross-account trust coverage: valid identities and reachable metadata remain the fastest path from agent infrastructure to customer cloud.

What to actually do

  1. Upgrade to 1.35.0 or later (1.36.0 is current as of early November), then do the audits — in that order. The 1.25.0 fix does not cover the SSRF, and neither fix cleans up planted state.
  2. Audit the scope store first. In mcp_scopes, hunt group_mappings to mcp-registry-admin and ui_permissions mutating-to-all grants; remove anything without an administrator's fingerprints. This is the step whose absence leaves a persistent admin.
  3. Hunt the logs for the two primitives. POST /api/servers/groups/import from non-admins, then any upstream-URL host change on registered servers. Either one in the affected-version window means assume the deployment's stored credentials and cloud role are in scope for rotation.
  4. Treat the gateway as SSRF-capable infrastructure. Egress-allowlist the registry and auth-server components, require IMDSv2, and scope attached cloud roles to least privilege — the bulletin recommends all three, and they bound the next validation gap too.
  5. Inventory forks and derivatives. AWS explicitly asks that forked or derivative code be patched; an internal fork pinned at 1.24.x carries both flaws regardless of what upstream fixed.

Our verification was read-only. We read AWS Security Bulletins 2026-179-AWS (CVE-2026-100307, 12:30 PM PST) and 2026-180-AWS (CVE-2026-125926, 1:00 PM PST) first-hand in full on 12 November 2026, including impacted-version ranges, resolution and post-upgrade sections, workarounds, references, and the novice-22 acknowledgement. We read GHSA-rxf3-qgpv-wxvr (High, CVSS 8.8, published 11 November 2026) and GHSA-fc39-fwh3-wv5r (High, CVSS 8.5, published 11 November 2026) via the GitHub Advisory API, confirmed release tags 1.25.0 and 1.35.0 (29 October 2026) plus 1.36.0 via the repository releases API, and confirmed both NVD records in Received state. Neither bulletin claims in-the-wild exploitation, and neither do we. We ran no registry, crafted no request, and contacted no vendor. Brave Search was used for discovery only.

Sources: