al-ice.ai

The Gateway That Aggregates Your MCP Servers Aggregates the Blast Radius Too — Two Unpatched MetaMCP CVEs

AI Vulnerabilities & CVEs by al-ice.ai Editorial

NVD published two MetaMCP advisories on 29 September 2026, both credited to Abhijeet Kumar of Traceforce and both filed against MetaMCP through v2.4.22 and the ai-dev branch at commit ff4ff2d. CVE-2026-79538 is command execution in the inspector proxy — NVD scores it 9.8 Critical (CWE-94), the vendor advisory 9.9 (CWE-78 OS command injection). CVE-2026-79537 is a cross-tenant session hijack rated 8.7 High by the vendor (CWE-639 plus CWE-306). Traceforce's advisories, both published 22 September 2026, state that no patched release had been identified as of that date. MetaMCP is an MCP aggregator and gateway — 2,695 stars and 436 forks on GitHub at the time of writing — whose entire job is to sit in front of every other MCP server you run. That is what makes these two bugs worse than their scores suggest.

CVE-2026-79538: the debugging tool is the shell

MetaMCP ships an inspector proxy so an operator can launch and test their own configured MCP servers from the UI. For the STDIO transport, the handler at GET /mcp-proxy/server/stdio (createTransport, STDIO branch, routers/mcp-proxy/server.ts) takes the process parameters straight from the request rather than resolving them from a server record the caller actually owns — and checks them against no allowlist. Supply the process, supply the arguments, and the container runs them.

Three details turn that from a developer footgun into a network-reachable critical. First, the frontend forwards the inspector proxy routes to the backend, so the handler is exposed on the public frontend port, not bound to localhost. Second, the only gate is any valid user session — and Traceforce notes that self-registration with email and password is enabled by default and may permit account creation without email verification, so an anonymous visitor can register, obtain a session, and reach the proxy. Third, the researchers reproduced command execution and secret disclosure in a controlled deployment; they explicitly state no third-party host was tested, and that the demonstrated execution context is an unprivileged application container with host-level root not established. That last qualifier is why NVD's 9.8 (which models PR:N) and the vendor's 9.9 (PR:L, scope-changed) disagree on the arithmetic while agreeing on the verdict.

Traceforce names the ancestor directly: this is the same class as CVE-2025-49596, the MCP Inspector proxy-spawn RCE that Oligo Security disclosed in June 2025 against Inspector versions below 0.14.1. The differences are the ones that matter operationally — that bug was localhost-only and unauthenticated; this one is public-port and gated by a registration form. We have watched this exact pattern recur all year, from the MCPJam Inspector RCE to Microsoft's DebugMCP drive-by: the MCP debugging surface keeps shipping a process-spawn primitive with a weaker authentication story than the thing it debugs.

CVE-2026-79537: routing by a header nobody validates

The second bug is quieter and, for a multi-tenant deployment, arguably the more damaging. MetaMCP's session store (getSession in session-lifetime-manager.ts) is keyed only by the client-supplied mcp-session-id header — no owner, namespace, or endpoint binding. On dispatch, the transport handler looks the session up by that header and forwards the request into whatever session it finds. The per-endpoint authorization middleware (api-key-oauth.middleware.ts) validates only that the caller may use the URL endpoint; it never checks that the session belongs to that endpoint, that namespace, or that caller. A caller using their own endpoint therefore passes the check and is then dispatched into the victim's namespace.

Session IDs are random, which would normally make this a theoretical hole. It is not, because GET /metamcp/health/sessions returns live session IDs and the namespace UUIDs they are connected to, without authentication. The unauthenticated endpoint supplies the secret the authenticated bypass requires. Traceforce reproduced the cross-tenant access in a controlled deployment, including a variant needing no credentials at all against an endpoint with authentication disabled.

The impact is precisely scoped in the advisory, and we will not inflate it: this is not host compromise. It is the ability to list and call another tenant's private MCP tools and read their data using the victim's forwarded upstream credentials. Whatever that tenant connected — files, databases, SaaS accounts — the attacker acts against as them. That is the aggregator's structural hazard: identity confusion at a gateway inherits every downstream credential at once, the same failure shape as the Terraform MCP server's cross-tenant token boundaries and Flowise's cross-workspace key theft.

No patch, and a repository with no security policy

Both advisories were reported via MITRE and to the maintainers on 24 August 2026, assigned CVE IDs on 10 September, published by Traceforce on 22 September, and hit NVD on 29 September — with the "Patched version" field left empty in both. The public signals corroborate the gap: MetaMCP's GitHub releases page lists v2.4.22 (19 December 2025) as the most recent tagged release, the default branch was last pushed 22 June 2026, and the issue tracker currently carries open requests titled "Create SECURITY.md for security policy," "No Security.Md ?" and "Request: enable Private Vulnerability Reporting for metamcp." A 2,695-star gateway that brokers other people's credentials has no published channel for receiving reports about doing that badly. That is not a footnote; it is the reason a 24 August report was still unpatched on 30 September.

What to do today

  • Block /mcp-proxy/ at the reverse proxy now. Traceforce's own interim guidance: deny external access to the inspector proxy path prefix. This is the highest-value single control, and it costs you only the in-browser server-testing UI.
  • Turn off open self-registration. The critical RCE's only gate is a valid session, and default self-registration may hand one out without email verification. Disable it, then audit existing accounts for registrations you did not expect.
  • Authenticate or remove /metamcp/health/sessions. Strip raw session and namespace IDs from any health response. A liveness probe should never be a key-distribution service.
  • Rotate every secret in an exposed deployment's environment — database credentials and the authentication signing secret included. Secret disclosure was reproduced, so treat exposure as assumed rather than proven-absent.
  • Do not run endpoints with authentication disabled on a reachable network. The credential-free variant of the hijack exists only against those endpoints. If you use them for internal convenience, bind them to a network an attacker cannot reach.
  • Treat MCP gateways as tier-0 identity infrastructure. An aggregator holding N tenants' upstream credentials is not "a proxy" — it is a credential vault with a protocol parser bolted on. Apply the review, network placement, and patch SLA you give an identity provider, a lesson the Obot five-CVE batch and Bifrost's off-by-default admin auth already taught at your expense.

Sources: