Unpatched MetaMCP Flaws Let Any Self-Registered User Run Commands and Hijack Other Tenants’ MCP Tool Sessions

Two critical vulnerabilities in MetaMCP, a widely starred open-source gateway that aggregates Model Context Protocol (MCP) servers behind shared endpoints, remain unpatched nearly two weeks after public disclosure. CVE-2026-79538 (CVSS 9.8) lets anyone who can create an account on a MetaMCP instance — and self-registration is on by default — execute commands inside the application container through the built-in MCP inspector proxy. CVE-2026-79537 (CVSS 9.1) breaks tenant isolation: MCP sessions are identified only by a client-supplied header, and an unauthenticated health endpoint lists the live session IDs. An attacker can therefore drive another tenant's private tools with that tenant's own upstream credentials. Both flaws affect MetaMCP up to and including 2.4.22. There is no fixed release, so operators must rely on network and configuration controls until the maintainers respond.

What MetaMCP is and why these flaws matter

MetaMCP describes itself as an "MCP Aggregator, Orchestrator, Middleware, Gateway in one docker." Its README presents it as multi-tenant: organisations deploy it on their own infrastructure, and users create their own MCP servers, namespaces, endpoints and API keys. Clients such as Claude Desktop or Open WebUI then connect to MetaMCP endpoints over SSE or Streamable HTTP. MetaMCP sits between AI agents and the databases, file systems and SaaS accounts those agents act on, and it forwards each tenant's credentials to its upstream servers. That makes it a credential broker, and a flaw in it reaches every connected system.

Both issues were found by Abhijeet Kumar of Traceforce. According to Traceforce's timeline, they were reported through MITRE and to the project maintainers on 24 August 2026, CVE IDs were assigned on 10 September, and the researcher's advisories went public on 22 September with no patch available. NVD and the GitHub Advisory Database published the CVE records on 29 September.

CVE-2026-79538: inspector proxy spawns attacker-chosen processes

The vulnerable code is the internal MCP inspector proxy endpoint GET /mcp-proxy/server/stdio, specifically the STDIO branch of createTransport in routers/mcp-proxy/server.ts. The CVE record classes it as CWE-94 (Code Injection). Traceforce also lists CWE-78 (OS Command Injection).

The inspector proxy exists so users can launch and test MCP servers they have configured. Traceforce found that for the STDIO transport, the handler accepts process parameters directly from the request "rather than resolving them from a server record the caller owns," and does not check them against an allowlist. Three other conditions make this remotely reachable:

• The routes are publicly exposed. The MetaMCP frontend forwards inspector proxy routes to the backend, so they are reachable on the public frontend port, not just localhost.
• The only gate is a session. Any valid user session passes.
• Sessions are free. Email-and-password self-registration is enabled by default and, according to Traceforce, "may permit account creation without email verification." The project's example.env confirms BOOTSTRAP_DISABLE_REGISTRATION_UI defaults to false.

Traceforce compares the bug to CVE-2025-49596, the MCP Inspector proxy-spawn issue. The difference here is that the handler is exposed on a public frontend and protected only by a session anyone can register for. The researcher reproduced command execution and secret disclosure in a controlled deployment. The demonstrated execution context is an unprivileged application container, and Traceforce says host-level root access "was not established." Even so, the container environment holds the database credentials and the authentication signing secret, which Traceforce lists as secrets to rotate. With those values an attacker could reach tenant data or forge sessions.

CVE-2026-79537: cross-tenant session hijack via an unchecked header

The second flaw is an insecure direct object reference (CWE-639). MetaMCP's session store, getSession in session-lifetime-manager.ts, is keyed only by the client-supplied mcp-session-id header, with no binding to an owner, namespace or endpoint. Traceforce names the affected dispatch paths as routers/public-metamcp/streamable-http.ts, the SSE /message variant and routers/mcp-proxy/metamcp.ts. The authorization middleware, api-key-oauth.middleware.ts, checks only that the caller may use the endpoint named in the URL; it never checks the session.

An attacker can therefore call their own endpoint, or any endpoint with authentication turned off, pass the authorization check, and supply a victim's session ID. The request is then dispatched into the victim's namespace. Session IDs are random, but GET /metamcp/health/sessions requires no authentication and returns active session IDs along with the namespace UUIDs they are attached to.

The result, per the CVE description, is that an attacker "can list and execute the victim tenant's private MCP tools and exfiltrate their data using the victim's forwarded credentials." Traceforce notes that, depending on what the victim has connected, this can mean reading files, reading or writing databases, or acting on SaaS accounts as the victim. It also reproduced a variant needing no credentials at all, against an endpoint with authentication disabled. The impact stays at the tool and data layer rather than the host.

Exploitation status and scoring

There are no public reports of in-the-wild exploitation, and neither CVE is in CISA's KEV catalog. Traceforce says it tested only in a controlled environment and against no third-party hosts. The scores differ by source:

The researcher's vector for CVE-2026-79538 assumes a low-privileged session (PR:L). With default open registration, that session costs an attacker nothing to obtain, which is why the CVE record scores it as requiring no privileges.

Affected versions and patch status

The project's public issue tracker includes open, unrelated reports about authorization scoping. One, filed 7 September, says server lookup by name is not user-scoped in three middleware paths. Another, filed 13 September, offers to contribute policy enforcement and auditing for tool calls. With no release since December 2025, defenders should not count on a fix arriving soon.

Defensive playbook

1. Take MetaMCP off untrusted networks. Traceforce's first recommendation is to restrict public access and limit deployments to trusted networks until a patch exists.
2. Block the inspector proxy at the edge. Deny the /mcp-proxy/ path prefix at your reverse proxy. Example for nginx in front of the MetaMCP frontend:

   location ^~ /mcp-proxy/ {
       return 403;
   }
   location = /metamcp/health/sessions {
       allow 127.0.0.1;
       deny all;
   }

   Test before and after: the inspector UI will stop working for users, which is the intended trade-off.
3. Disable open registration. In the admin UI go to Settings → Authentication Settings and enable "Disable UI Registration" (and "Disable SSO Registration" if you do not need it), or set BOOTSTRAP_DISABLE_REGISTRATION_UI=true in the environment. Then review the user table for accounts nobody recognises.
4. Close the session-ID leak. Require authentication on /metamcp/health/sessions or block it externally, as above. Do not run endpoints with authentication disabled on any reachable network.
5. Rotate secrets. For any deployment that was reachable, rotate everything in the container environment, including the database credentials and the authentication signing secret. Also rotate the upstream API keys and OAuth tokens tenants have connected to their MCP servers.
6. Hunt in proxy logs. These are starting points built from the endpoints named in the advisories; adapt the field positions to your log format:

   # Any use of the STDIO inspector proxy route
   grep -E 'GET /mcp-proxy/server/stdio' /var/log/nginx/access.log
   
   # Unauthenticated session enumeration
   grep -E 'GET /metamcp/health/sessions' /var/log/nginx/access.log | awk '{print $1}' | sort | uniq -c | sort -rn

   If your proxy logs the mcp-session-id request header, alert when one session ID shows up from more than one client IP or authenticated principal.
7. Plan for the long term. If you need a multi-tenant MCP gateway in production, assess whether an unmaintained project fits your risk appetite. At minimum, apply the code-level fixes Traceforce describes in a fork: derive STDIO process parameters only from the caller's saved server records, and bind each session to its owning endpoint and namespace, checked before dispatch.