plaincve:~$

// threat brief

CVE-2026-79538

MetaMCP inspector proxy command injection: processes launched from request parameters can run commands in the container

CVSS
9.8 CRITICAL
CISA KEV
Not listed
Weakness
CWE-78 · CWE-94
Topics
AI security · Web apps

PlainCVE Team · Published 2026-10-07 · AI-assisted · Press brief ↓

AI review 2026-10-07 (not human-reviewed)Command tests: none yetReproduced: not yetVerification record ↓

MetaMCP's inspector proxy starts processes from request-supplied parameters, which may let an attacker run commands in its container. No patch yet.

Who is affectedOrganizations self-hosting metatool-ai MetaMCP 2.4.22 or earlier, especially deployments where the /mcp-proxy/ path is reachable from a public network. An attacker needs a valid login session (the researcher's statement, consistent with PlainCVE's reading of the v2.4.22 source code), but self-registration is open by default, so the bar may be low. The CISA ADP CVSS rating in the CVE record says no privileges are needed (PR:N), which does not match the code.
What happensAccording to the researcher, an attacker may run commands inside the application container, read secrets available to it (such as database credentials and the authentication signing secret), and may access tenant data or forge login sessions. The researcher's demonstration did not gain root on the host.
What to do nowNo patched release has been identified (none found by the researcher as of 2026-09-22, and none in the sources we reviewed). The researcher advises blocking /mcp-proxy/ at the reverse proxy, turning off open self-registration, and keeping deployments on trusted networks; any deployment that was exposed should have all of its environment secrets replaced.
Affected versionsUp to and including 2.4.22; the researcher also names commit ff4ff2d on the ai-dev branch
Fixed versionsNone yet (the researcher found no patched release as of 2026-09-22)
CVSS vector
Show full vectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
Timeline
  • First public 2026-09-29

Blue team playbook

Check, fix / mitigate, respond, harden. Matching the affected versions does not mean you were compromised, and a check that finds nothing does not prove you are safe; each item says what it can and cannot show. Tagged steps point to where the attack flow below can be stopped.

DETECTCheckAm I affected? Any signs of compromise?
  1. 01Check your version and exposure

    MetaMCP 2.4.22 and earlier are affected. Our analysis: 2.4.22 is the newest release on the project's releases page, so every published release is likely affected. Then check whether /mcp-proxy/ is reachable from a public network and whether self-registration is open.

    Read-only check
    docker image ls | grep -i metamcp
    Step 1Step 2
  2. 02Search access logs for STDIO proxy requests

    Look in your reverse proxy access logs for requests to /mcp-proxy/server/stdio, especially from outside addresses or newly registered accounts. No source gives official detection guidance; this check is PlainCVE's suggestion based on the affected endpoint.

    Read-only check
    grep -F '/mcp-proxy/server/stdio' /var/log/nginx/access.log
    Step 2Step 3
MITIGATEFix / mitigatePatch; block it if you cannot patch yet
  1. 01Block /mcp-proxy/ at the reverse proxy

    The researcher's advice: until a patch exists, block external access to paths starting with /mcp-proxy/ at the reverse proxy.

    Step 2
  2. 02Turn off open self-registration

    The researcher advises turning off the default open self-registration so strangers cannot create their own accounts and sessions.

    Step 1
  3. 03Keep deployments on trusted networks

    The researcher advises restricting public access and limiting deployments to trusted networks until a patch is available.

    Step 2
RESPONDRespondIf you find signs of compromise
  1. 01Rotate every secret in the environment

    The researcher's advice: if a deployment was exposed, replace all secrets in its environment, the database password and the login-signing key among them. The researcher also says a successful attack may let an attacker forge sessions. PlainCVE's suggestion (not from the researcher): after rotation, treat sessions created before the rotation as untrusted.

    Step 5
HARDENHardenPrevent the next one
  1. 01Watch for a fix and check how it works

    The researcher suggests deriving process parameters from the user's saved server records, or removing raw process execution from the inspector proxy entirely. When the maintainers ship an update, check whether it follows this approach.

    Step 3
  2. 02Don't expose MCP management tools directly to the internet

    PlainCVE's suggestion (building on the researcher's advice to restrict public access and keep deployments on trusted networks): keep debugging and management features such as the inspector unreachable from public networks.

    Step 2
Full remediation steps and notes

No patched release has been identified, and no maintainer advisory appears in the sources we reviewed. The measures (blocking /mcp-proxy/, disabling self-registration, trusted networks only, rotating secrets) come from the researcher; the ordering and reasoning below are PlainCVE’s suggestion.

  1. Block the path, then close registration. Blocking /mcp-proxy/ cuts off the attack path. Turning off self-registration raises the bar, but accounts that already exist (including any strangers who registered earlier) still have sessions, so that alone is not enough; do both.
  2. Rotate first or block first? Block first, then rotate. If you rotate while the path is still open, the new secrets could leak again. The researcher’s rotation list includes database credentials and the authentication signing secret. The sources we reviewed do not say whether changing the signing secret ends existing logins.
  3. While waiting for a fix. When the maintainers ship a new version, check whether it takes parameters from the user’s own saved server records or removes raw process execution.

Attack flow

Read left to right: this is the order the attack happens in. A blue shield means the step can be stopped; the earlier, the better. Click an icon for details.

Read top to bottom: this is the order the attack happens in. A blue shield means the step can be stopped; the earlier, the better. Tap an icon for details.

MetaMCP inspector proxy command injection: processes launched from request parameters can run commands in the container: 1. Gets a logged-in session → 2. Reaches the inspector proxy routes through the public frontend → 3. The STDIO handler starts a process as the request says → 4. Commands run inside the application container → 5. Reads secrets available to the containerCVE-2026-79538 · MetaMCP inspector proxy command injection: processes launched from request parameters canrun commands in the containerAttackerYour systemGets a logged-in session — The researcher says any valid user session is enough. Self-registration with email and password is on by default and may not require email verification, so an anonymous visitor may be able to get an account. In the v2.4.22 code, every /mcp-proxy/server route (including /stdio) goes through betterAuthMcpMiddleware, which rejects requests without a logged-in session (HTTP 401), consistent with the researcher. The CISA ADP CVSS rating in the CVE record says no privileges are needed (PR:N), which does not match the code. 1Gets a logged-insessionReaches the inspector proxy routes through the public frontend — The researcher notes that the frontend forwards the inspector proxy routes to the backend, so /mcp-proxy/ is reachable on the public frontend port. 2Reaches theinspector proxyroutes through thepublic frontendThe STDIO handler starts a process as the request says — According to the researcher, the GET /mcp-proxy/server/stdio handler uses whatever program settings arrive with the request. It neither fetches them from a saved server entry belonging to the user nor compares them with a list of permitted programs. 3The STDIO handlerstarts a processas the request saysCommands run inside the application container — In the researcher's demonstration, code ran in an unprivileged application container; host root access was not established. 4Commands runinside theapplicationcontainerReads secrets available to the container — The researcher says that if the attack works, secrets held by the container could leak, and an attacker might then reach tenant data or fake sessions. The researcher reproduced secret disclosure in a controlled deployment. 5Reads secretsavailable to thecontainerAttack pathCan be stopped herePlainCVE · plaincve.date/en/vulns/cve-2026-79538-metamcp-inspector-proxy-rce · CC BY 4.0
MetaMCP inspector proxy command injection: processes launched from request parameters can run commands in the container: 1. Gets a logged-in session → 2. Reaches the inspector proxy routes through the public frontend → 3. The STDIO handler starts a process as the request says → 4. Commands run inside the application container → 5. Reads secrets available to the containerCVE-2026-79538 · MetaMCP inspector proxycommand injection: processes launchedfrom request parameters can run commandsin the containerGets a logged-in session — The researcher says any valid user session is enough. Self-registration with email and password is on by default and may not require email verification, so an anonymous visitor may be able to get an account. In the v2.4.22 code, every /mcp-proxy/server route (including /stdio) goes through betterAuthMcpMiddleware, which rejects requests without a logged-in session (HTTP 401), consistent with the researcher. The CISA ADP CVSS rating in the CVE record says no privileges are needed (PR:N), which does not match the code. 1AttackerGets a logged-in sessionReaches the inspector proxy routes through the public frontend — The researcher notes that the frontend forwards the inspector proxy routes to the backend, so /mcp-proxy/ is reachable on the public frontend port. 2AttackerReaches the inspector proxyroutes through the publicfrontendThe STDIO handler starts a process as the request says — According to the researcher, the GET /mcp-proxy/server/stdio handler uses whatever program settings arrive with the request. It neither fetches them from a saved server entry belonging to the user nor compares them with a list of permitted programs. 3Your systemThe STDIO handler starts aprocess as the request saysCommands run inside the application container — In the researcher's demonstration, code ran in an unprivileged application container; host root access was not established. 4Your systemCommands run inside theapplication containerReads secrets available to the container — The researcher says that if the attack works, secrets held by the container could leak, and an attacker might then reach tenant data or fake sessions. The researcher reproduced secret disclosure in a controlled deployment. 5AttackerReads secrets available to thecontainerAttack pathCan be stopped herePlainCVE · CC BY 4.0plaincve.date/en/vulns/cve-2026-79538-metamcp-inspector-proxy-rce
Free to use in reporting and teaching under CC BY 4.0. Attribution is already on the image.
  1. Attacker

    Gets a logged-in session

    The researcher says any valid user session is enough. Self-registration with email and password is on by default and may not require email verification, so an anonymous visitor may be able to get an account. In the v2.4.22 code, every /mcp-proxy/server route (including /stdio) goes through betterAuthMcpMiddleware, which rejects requests without a logged-in session (HTTP 401), consistent with the researcher. The CISA ADP CVSS rating in the CVE record says no privileges are needed (PR:N), which does not match the code.

    Defense: Turn off open self-registration (researcher's advice).

  2. Attacker

    Reaches the inspector proxy routes through the public frontend

    The researcher notes that the frontend forwards the inspector proxy routes to the backend, so /mcp-proxy/ is reachable on the public frontend port.

    Defense: Block external access to /mcp-proxy/ at the reverse proxy; run deployments only on trusted networks.

  3. Your system

    The STDIO handler starts a process as the request says

    According to the researcher, the GET /mcp-proxy/server/stdio handler uses whatever program settings arrive with the request. It neither fetches them from a saved server entry belonging to the user nor compares them with a list of permitted programs.

    Defense: No official fix yet. The researcher's suggested code fix: derive parameters from the caller's saved server records, or remove raw process execution from the inspector proxy.

  4. Your system

    Commands run inside the application container

    In the researcher's demonstration, code ran in an unprivileged application container; host root access was not established.

  5. Attacker

    Reads secrets available to the container

    The researcher says that if the attack works, secrets held by the container could leak, and an attacker might then reach tenant data or fake sessions. The researcher reproduced secret disclosure in a controlled deployment.

    Defense: If a deployment was exposed, replace all of its environment secrets, such as the database password and the key used to sign logins (researcher's advice).

Who is affected

ConditionAffected?
MetaMCP 2.4.22 or earlierAffected (CVE record)
ai-dev branch commit ff4ff2dAffected (per the researcher)
Any patched releaseNone found by the researcher as of 2026-09-22; no source lists one

Our analysis: the newest release on the maintainers’ releases page is 2.4.22, so every published release is likely in the affected range. This is PlainCVE’s inference, not a statement from the maintainers; their repository and releases page do not mention this CVE.

The highest risk is for deployments where /mcp-proxy/ is reachable from a public network and self-registration is open. The researcher notes that the frontend forwards these routes to the backend, so they are reachable on the public frontend port.

How it works

MetaMCP manages several MCP servers in one place (MCP is a protocol that lets AI call external tools). It includes an “inspector proxy” that lets users test connections. One connection type is STDIO: the server starts a program and talks to it through its standard input and output.

According to the researcher, the handler for GET /mcp-proxy/server/stdio (the STDIO branch of createTransport in routers/mcp-proxy/server.ts) uses the process parameters supplied in the request to start the program. It does not look up a server configuration the user has saved, and it does not filter against an allowlist. So the user decides what the server runs. The researcher classifies this as command injection (CWE-78) and code injection (CWE-94); the CVE record (CISA ADP) lists only CWE-94.

The flawed approach (conceptual illustration, not the original source code):

Show code example(ts)
// How the process starts is decided entirely by the request
const params = readProcessParamsFrom(request);
startStdioProcess(params);

The fixed approach (the direction the researcher suggests; no official fix exists yet):

Show code example(ts)
// Take parameters only from a server record this user saved
const record = loadSavedServer(request.serverId, { owner: session.userId });
if (!record) reject();
startStdioProcess(record.params);

The researcher’s other suggestion is to remove raw process execution from the inspector proxy entirely. The researcher also says this is the same class of bug as CVE-2025-49596 in the upstream MCP Inspector.

A valid login session is required. The researcher says any valid session is required (CVSS 9.9, PR:L, changed scope S:C). PlainCVE checked the v2.4.22 source: apps/backend/src/routers/mcp-proxy/server.ts applies the authentication middleware with serverRouter.use(betterAuthMcpMiddleware) before any route (including /stdio) is defined, and apps/backend/src/middleware/better-auth-mcp.middleware.ts returns 401 when there is no session cookie, when session verification fails, or when there is no user; we saw no exception conditions. This matches the researcher. The CISA ADP rating in the CVE record says no privileges are needed (CVSS 9.8, PR:N, S:U), which does not match the code. Still, self-registration is on by default and may not require email verification, so the bar may be low.

In the researcher’s demonstration, commands ran in an unprivileged application container and did not gain root on the host. Secrets in the container could still be exposed, and they may be used to access tenant data or forge sessions.

Timeline

DateEvent
2026-08-24Researcher reports the issue to MITRE and the project maintainers
2026-08-25CVE record shows the ID as reserved
2026-09-10Researcher says MITRE assigned the CVE ID
2026-09-22Date shown on the Traceforce researcher article; no patched release found (the maintainers have not published a project advisory)
2026-09-29CVE record published (this page’s first-disclosure date, per the CVE record’s datePublished); CISA’s SSVC assessment records exploitation as “none”
2026-10-01Still not listed in CISA KEV

Further reading

  • Scoring differences: the CVE record (CISA ADP) gives CVSS 3.1 9.8 (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H); the researcher gives 9.9 (AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H). They differ on whether login is required and whether the impact reaches beyond the vulnerable component. This page follows the v2.4.22 code (an authentication middleware applied to the /mcp-proxy/server routes) and says login is required, matching the researcher’s PR:L; the score at the top of the page is still the CVE record’s (CISA ADP) 9.8.
  • CWE differences: CISA ADP lists only CWE-94; the researcher lists CWE-78 and CWE-94.
  • Exploitation: not in CISA KEV; the CISA ADP SSVC entry in the CVE record records no exploitation (Exploitation: none); the aggregator The Hacker Wire says no public exploit code has been confirmed. There is no evidence either way on exploitation before a fix existed.
  • The GitHub Advisory Database lists an EPSS (estimated chance of exploitation in the next 30 days) of about 0.4%.
  • Credit: Abhijeet Kumar of Traceforce.
  • Related: CVE-2025-49596 (remote code execution via process spawning in the MCP Inspector proxy).

Verification Checked item by item against sources by AI under our review rules, all passed; not human-reviewed and not yet reproduced in our lab

AI review2026-10-07 · review rules

Verification records describe the environment and the result only, never reproduction steps or code that could attack other people’s systems. See our policy.

Sources

  1. CVE / NVD / OSVCVE-2026-79538 Record (CVE Services API) · CVE Program / MITRE, 2026-09-29 · accessed 2026-10-01
  2. ResearchCVE-2026-79538: Authenticated OS command injection and container RCE in metatool-ai/metamcp · Traceforce, 2026-09-22 · accessed 2026-10-01
  3. Vendormetatool-ai/metamcp releases · metatool-ai (GitHub) · accessed 2026-10-01
  4. Vendormetamcp v2.4.22 source, apps/backend/src/routers/mcp-proxy/server.ts · metatool-ai (GitHub) · accessed 2026-10-07
  5. Vendormetamcp v2.4.22 source, apps/backend/src/middleware/better-auth-mcp.middleware.ts · metatool-ai (GitHub) · accessed 2026-10-07
  6. OtherGitHub Advisory Database entry for CVE-2026-79538 · GitHub · accessed 2026-10-01
  7. OtherCVE-2026-79538 threat entry · OffSeq Radar · accessed 2026-10-01
  8. NewsCVE-2026-79538 · The Hacker Wire · accessed 2026-10-01

Press brief

In one sentence

MetaMCP is open-source software for managing MCP servers, the services that let AI call external tools, in one place. A researcher found that its built-in inspector proxy endpoint starts programs exactly as a request tells it to, which may let an attacker run commands inside the application container and read its secrets. Versions up to and including 2.4.22 are affected, and no patched release had been identified as of September 22, 2026. There are no reports of exploitation in the wild, and it is not on CISA's Known Exploited Vulnerabilities list.

Key facts

Severity
CVSS 3.1 9.8 (CVE record); researcher's own score 9.9 cveawg.mitre.org
Affected versions
Up to and including 2.4.22 cveawg.mitre.org
Patch status
No patched release as of 2026-09-22 traceforce.ai
CVE published
2026-09-29 cveawg.mitre.org
Discovered by
Abhijeet Kumar (Traceforce) traceforce.ai
EPSS
About 0.4% (GitHub Advisory Database) api.github.com

Confirmed

  • The CVE record confirms a code execution flaw in the GET /mcp-proxy/server/stdio endpoint of MetaMCP 2.4.22 and earlier.
  • The researcher reproduced command execution and secret disclosure inside the container in a controlled deployment.
  • As of 2026-10-01 it is not in CISA KEV, and CISA's SSVC assessment records exploitation as "none".

Unconfirmed / disputed

  • Whether the login check has exceptions in real deployments: the v2.4.22 authentication middleware code PlainCVE reviewed has no exception conditions, but we have not tested a live deployment.
  • No maintainer advisory, fix commit or patched release appears in the sources reviewed, and the maintainers' pages do not mention the CVE.
  • There is no evidence on whether it was exploited before a fix existed, and no public exploit code has been confirmed.

Quotable line

An endpoint meant for debugging ended up letting users decide which program the server runs.

Images

Download the share image (PNG) · Attack flow diagram (downloadable)

Please credit "PlainCVE" and link to this page. Full citation format is under "How to cite" below. Found a factual error? Report it.

How to cite this page

This article is CC BY 4.0. Please keep the attribution and link when republishing.

PlainCVE Team (2026). "MetaMCP inspector proxy command injection: processes launched from request parameters can run commands in the container". PlainCVE. https://plaincve.date/en/vulns/cve-2026-79538-metamcp-inspector-proxy-rce (accessed YYYY-MM-DD)
BibTeX
@misc{cve202679538metamcpinspectorproxyrce2026,
  title  = {MetaMCP inspector proxy command injection: processes launched from request parameters can run commands in the container},
  author = {PlainCVE Team},
  year   = {2026},
  howpublished = {PlainCVE},
  url    = {https://plaincve.date/en/vulns/cve-2026-79538-metamcp-inspector-proxy-rce},
  note   = {Updated 2026-10-07}
}