Systemic MCP stdio RCE class — 200,000+ servers exposed (May 2026)

View raw markdownEdit on GitHub ↗

TL;DR

OX Security disclosed a systemic, class-level vulnerability in the Model Context Protocol's stdio transport in May 2026. Audit of public-facing instances found 7,000 vulnerable MCP servers on public IPs running stdio transport; extrapolation puts the total exposed population at ~200,000 servers across the ecosystem (~150M+ downloads of affected packages). Anthropic classifies it as a feature, not a bug; defenders should treat it as a class issue and harden accordingly.

What happened

The MCP stdio transport assumes a trust boundary that doesn't actually exist in many deployments. When MCP servers are exposed network-side (or trigger-able through composition with other tools), prompt-injectable content can reach the server's stdin, and instructions interpreted there execute as the host process — Arbitrary Command Execution.

Headline numbers: - 7,000 vulnerable servers found on public IPs with stdio transport active. - ~200,000 total estimated from sampling ratios. - 150M+ downloads of affected MCP packages.

Three database-targeting MCPs were also disclosed by the same researcher on 2026-05-13 with concrete impact: - Apache Doris MCP — unintended SQL execution. Apache issued a patch and CVE tracker. - Alibaba RDS MCP — sensitive metadata exfiltration. Alibaba declined to patch. - Apache Pinot MCP — instance takeover for internet-exposed Pinot instances.

Microsoft's own MCP server has now had two disclosures in this class: - CVE-2026-26118 — Server-Side Request Forgery in Azure MCP Server letting an authorized attacker elevate privileges over the network (patched in the March 2026 update). - CVE-2026-32211 (CVSS 9.1) — missing authentication on a critical Azure MCP Server function: any unauthenticated network-reachable attacker can read sensitive data (config, API keys, auth tokens, project data). Published 2026-04-03; at disclosure no patch was available, only network-control mitigation. Same root failure as nginx-ui MCPwn — an MCP surface trusted by default.

Update 2026-08-05 — a third "Azure + MCP" CVE, but a different (community) project this time: CVE-2026-33980 / GHSA-vphc-468g-8rfp (CVSS 8.3) is a KQL injection in adx-mcp-server — a community-maintained (pab1it0) MCP server for Azure Data Explorer, distinct from Microsoft's own first-party Azure MCP Server covered by the two CVEs above. Three tool handlers (get_table_schema, sample_table_data, get_table_details) build Kusto queries by directly interpolating the caller-supplied table_name via Python f-strings, with no validation — letting an attacker, or a prompt-injected AI agent calling the tool, execute arbitrary KQL against the connected Azure Data Explorer cluster. Publicly disclosed 2026-03-27; patched in commit 0abe0ee5. This reinforces the pattern already tracked here: "cloud-provider MCP" now spans both a vendor's own first-party server and multiple independent community wrappers targeting the same cloud service, each accumulating its own, separate CVE stream — check which one you're running before assuming a vendor patch covers you.

Named instance — Atlassian mcp-atlassian "MCPwnfluence" (CVE-2026-27825 + CVE-2026-27826): Pluto Security chained two flaws in the most widely used Atlassian MCP server (4M+ downloads, 4.4K+ stars) into unauthenticated RCE as root in two requests. mcp-atlassian's HTTP transport (--transport streamable-http) defaults to binding 0.0.0.0 with zero authentication, so anyone who can reach the port can invoke any tool. - CVE-2026-27826 (CVSS 8.2) — SSRF: middleware honors the X-Atlassian-Jira-Url / X-Atlassian-Confluence-Url headers without validation, letting an attacker point requests at arbitrary internal destinations. - CVE-2026-27825 (CVSS 9.1) — arbitrary file write: the confluence_download_attachment tool lacks directory-boundary enforcement, so the attacker writes content to any path the server process can reach. - Chained (SSRF → arbitrary write of an executable/cron/config), this is unauthenticated host takeover. Affects < 0.17.0; fixed in 0.17.0, which adds validate_safe_path() and validate_url_for_ssrf() (path confinement + scheme/domain allowlisting + redirect/localhost/private-IP blocking).

Named instance — network-ai empty-default-secret (CVE-2026-46701): the MCP SSE server in network-ai (npm) defaults to an empty shared secret, so its authorization check passes for everyone — an unauthenticated cross-origin attacker can invoke any MCP tool (and a sibling path-traversal lets it write arbitrary files on the host). Published 2026-05-21; affects < 5.4.5, fixed in 5.4.5. Same root failure as the others — an MCP surface that ships open by default (here the "auth" is real but the default credential is blank).

Named instance — aws-mcp-server unauthenticated RCE (CVE-2026-5058 + CVE-2026-5059, CVSS 9.8 each): Two sibling command-injection flaws in aws-mcp-server let a network-reachable, unauthenticated attacker run arbitrary code as the server process (CWE-78). Both reside in the server's handling of the allowed-commands list: user-supplied strings flow into a system call without proper neutralization, so the "allowlist" is bypassable. Published 2026-04-11; tracked by Zero Day Initiative as ZDI-26-245 / ZDI-26-246; patches at disclosure were still pending — pull the server off the network and monitor vendor channels for a fixed release. Critically, this is not AWS's official "AWS API MCP" product (which has its own, separate CVE-2026-4270 file-access-restriction bypass); aws-mcp-server is a popular community/third-party project. Treat as the AWS-credential analogue of the nginx-ui MCPwn class: an MCP surface shipped without auth that runs shell-style commands on input.

Named instance — n8n-mcp post-auth SSRF (CVE-2026-39974): The multi-tenant HTTP mode of n8n-mcp (a popular MCP server that exposes n8n node documentation/operations to AI assistants) takes user-controlled URLs from multi-tenant HTTP headers and issues server-side requests without adequate validation, reflecting the response body back through JSON-RPC. An authenticated attacker (valid AUTH_TOKEN) can read the contents of any URL the server can reach — most damagingly the cloud instance metadata services (AWS IMDS, GCP, Azure, Alibaba, Oracle) to harvest temporary credentials. Affects ≤ 2.47.3, fixed in 2.47.4, which adds SSRF protection that validates and rejects embedded-credential URLs and requests to restricted destinations. Lower severity than the unauthenticated MCP class (post-auth, no RCE), but a clean named instance of "MCP server reflects arbitrary HTTP responses back to the client."

Named instance — @mcpjam/inspector zero-auth RCE (CVE-2026-23744): the MCPJam Inspector (an MCP-server dev/debug tool) binds 0.0.0.0 by default and ships no authentication on its server-management endpoint, so any network-reachable attacker can send a crafted HTTP request that installs and runs a malicious MCP server → RCE, with no user interaction. Unlike the related CVE-2025-49596 (which bound 127.0.0.1 and needed user interaction), this one is exposed on all interfaces. Affects ≤ 1.4.2, fixed in 1.4.3 (disclosed Feb 2026; surfaced in this sweep). Same root failure: an MCP dev surface trusted-by-default and reachable off-host.

Named, KEV-listed instance — nginx-ui "MCPwn" (CVE-2026-33032, CVSS 9.8): the clearest real-world example of the "MCP endpoint shipped without auth" class. nginx-ui exposes two HTTP MCP endpoints, /mcp and /mcp_message. /mcp requires IP-allowlisting and AuthRequired() middleware; /mcp_message only gets IP-allowlisting — and the default IP allowlist is empty, which the middleware treats as "allow all." So an unauthenticated network attacker can invoke all 12 MCP tools (including nginx_config_add with auto-reload) and achieve full nginx takeover in two HTTP requests. ~2,600 exposed instances (Pluto Security / Shodan), actively exploited, added to VulnCheck KEV (2026-04-13) and named in Recorded Future's most-exploited-CVE list for March 2026. Fixed in nginx-ui 2.3.4 (2026-03-15); workaround is to add middleware.AuthRequired() to /mcp_message or flip the IP-allowlist default from allow-all to deny-all. This is an HTTP-transport auth-bypass rather than stdio, but it's the same root failure — an MCP surface treated as trusted-by-default.

Named instance — fast-mcp-telegram bearer-token path traversal (CVE-2026-52830, CVSS 9.4): a Telegram MCP server (PyPI) that lets AI agents send/read Telegram messages via MTProto validates its HTTP Bearer token by joining the raw token string directly into a session-file path, then checking whether that path exists — without rejecting path separators or normalizing the result. The verifier does block the literal reserved token telegram, but a token of ../fast-mcp-telegram/telegram traverses back to the documented default session file (~/.config/fast-mcp-telegram/telegram.session) and authenticates as that account with no valid bearer token at all. Any unauthenticated remote HTTP client can read/send messages and make arbitrary MTProto calls as the default Telegram identity. Affects ≤ 0.19.0, fixed in 0.19.1 (published 2026-07-02). Same root failure as every other entry here: an MCP surface that treats a caller-supplied string as a trusted path/credential without validating it stays inside its intended boundary.

Named instance — n8n-mcp cross-tenant backup exposure (CVE-2026-54052, CVSS 9.9, critical): a second, distinct n8n-mcp flaw from the SSRF above (CVE-2026-39974) — in multi-tenant HTTP deployments (ENABLE_MULTI_TENANT=true), workflow-version-history backups lacked tenant isolation entirely. Any authenticated user could read, delete, or destroy other tenants' stored workflow-version snapshots, which embed node definitions containing credential references and authorization headers. Not applicable to stdio/single-user deployments (e.g. Claude Desktop) or single-tenant HTTP mode. Published 2026-06-03 (re-indexed into GitHub's Advisory Database 2026-07-14); affects ≤ 2.56.0, fixed in 2.56.1, which isolates history per instance and runs a one-time migration clearing previously un-scoped backups. Same class as the rest of this advisory — an MCP surface that assumed a trust boundary its own data model didn't enforce — but the vector here is authorization/tenant-isolation rather than network exposure.

Named instance — @andrea9293/mcp-documentation-server unauthenticated Web UI/API (CVE-2026-54504, CVSS 8.8): this npm MCP server's Web UI/API listens on all interfaces by default (0.0.0.0:3080, not localhost-only) and its document-management endpoints ship with no authentication, letting any network-adjacent attacker enumerate, create, read, search, and delete documents without credentials. Published 2026-06-04 (indexed into GitHub's Advisory Database 2026-07-15); affects ≤ 1.13.0, fixed in 1.13.1. A textbook instance of the class this advisory tracks: bind-to-everything-by-default plus auth-is-optional.

Named instance — n8n-mcp default-scope backup exposure (CVE-2026-55608, CVSS 4.2, medium): a narrower follow-on to the cross-tenant backup flaw above (CVE-2026-54052) in the same package. In multi-tenant HTTP mode (ENABLE_MULTI_TENANT=true), an authenticated tenant could, under certain conditions, still reach n8n-mcp's local default-scope workflow_versions backups — leftover from single-tenant deployments or migrations — instead of being confined strictly to its own tenant scope. This is a distinct GHSA (GHSA-2cf7-hpwf-47h9) from CVE-2026-54052's (GHSA-j6r7-6fhx-77wx), confirmed by fetching both pages directly. Published 2026-07-14; affects < 2.57.4, fixed in 2.57.4. Same tenant-isolation-assumed-but-not-enforced root cause as CVE-2026-54052, scoped to a narrower leftover-data case.

Named instance — HashiCorp Terraform MCP Server, three CVEs (HCSEC-2026-23, CVE-2026-14869 / CVE-2026-16496 / CVE-2026-16498): HashiCorp's own official MCP server for Terraform, disclosed 2026-07-28, joining consul-mcp-server as the second HashiCorp first-party MCP server with a coordinated multi-CVE bulletin. CVE-2026-14869 (SSRF, CVSS 8.6) — the streamable-HTTP transport lets an unauthenticated remote client redirect the server's Terraform API requests, and its server-side authorization token, to an attacker-controlled endpoint (confirmed on NVD: CVSS vector AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:N/A:N, published 2026-07-28). CVE-2026-16496 (authorization bypass) — in stateful transport mode, a user who obtains another user's MCP session ID can have their own tool calls executed using that other user's Terraform credentials. CVE-2026-16498 (cross-tenant credential reuse) — in stateless transport mode, one user's Terraform token can be reused to execute tool calls on behalf of subsequent, unrelated users. All three affect 0.2.1 through 1.0.0, fixed in 1.1.0.

Named instance — mcp-server-kubernetes, presentation-layer-only access control + flag-injection token theft (CVE-2026-46519, CVE-2026-47250): a popular community MCP server (npm) that exposes Kubernetes cluster operations to AI agents. CVE-2026-46519 (CVSS 8.8, GHSA-cr22-wjx7-2w6m) — the server's access-control env vars (ALLOW_ONLY_READONLY_TOOLS, ALLOW_ONLY_NON_DESTRUCTIVE_TOOLS, ALLOWED_TOOLS) are enforced only at tool discovery (tools/list) and not at tool execution (tools/call) — any client that already knows a restricted tool's name can invoke it directly, making the "restriction" cosmetic. CVE-2026-47250 (CVSS 6.1, GHSA-6mx4-4h42-r8vh) — the kubectl_generic tool passes user-supplied flags to kubectl with no allowlist, letting an attacker with limited cluster access inject structured content into logs that, when a privileged operator later processes those logs through the MCP server, redirects kubectl's bearer token to an attacker-controlled endpoint — capturing the operator's full RBAC-scoped credentials. Both affect versions before their respective fixes: 3.6.0 (CVE-2026-46519) and 3.7.0 (CVE-2026-47250). Same "presentation-layer check, not an execution-layer boundary" root cause already tracked in this advisory's other entries, applied here to Kubernetes-scoped tool access control specifically.

Am I affected?

You are exposed by the class issue if:

  • You run any MCP server listening on a network socket (most MCPs are stdio-only by design, but composition with proxies / HTTP wrappers / web gateways changes this).
  • You connect your AI tool to an MCP that exposes any of: Apache Doris, Alibaba RDS, Apache Pinot, or similar DB engines.
  • You use Microsoft's Azure MCP Server — check against CVE-2026-26118 (SSRF, patched) and CVE-2026-32211 (missing auth, CVSS 9.1); restrict it to trusted networks until patched.
  • You run mcp-atlassian < 0.17.0 with its HTTP transport reachable (CVE-2026-27825 / -27826 / "MCPwnfluence") — it binds 0.0.0.0 with no auth by default; upgrade to ≥ 0.17.0 now.
  • You run nginx-ui < 2.3.4 with its MCP endpoint reachable (CVE-2026-33032 / "MCPwn") — patch now; it's in CISA/VulnCheck KEV and exploited in the wild.
  • You run network-ai < 5.4.5 (CVE-2026-46701) — its MCP SSE server ships an empty default secret; upgrade to ≥ 5.4.5 and set a non-empty secret.
  • You run @mcpjam/inspector ≤ 1.4.2 (CVE-2026-23744) — it binds 0.0.0.0 with no auth → zero-interaction RCE; upgrade to ≥ 1.4.3 and bind it to 127.0.0.1.
  • You run aws-mcp-server (community/third-party project) — CVE-2026-5058 / CVE-2026-5059 are unauthenticated, CVSS 9.8 command-injection RCEs; patches were pending at disclosure (2026-04-11), so remove it from any network-reachable path and watch the project + ZDI-26-245/-246 for a fixed release.
  • You run n8n-mcp ≤ 2.47.3 in multi-tenant HTTP mode (CVE-2026-39974) — authenticated SSRF that reflects responses back, including cloud IMDS; upgrade to ≥ 2.47.4.
  • You run fast-mcp-telegram ≤ 0.19.0 over HTTP (CVE-2026-52830) — its bearer-token check is bypassable via path traversal, letting anyone authenticate as your default Telegram session with no valid token; upgrade to ≥ 0.19.1.
  • You run n8n-mcp ≤ 2.56.0 in multi-tenant HTTP mode (CVE-2026-54052) — any authenticated user can read/delete other tenants' workflow-version backups, which embed credential references; upgrade to ≥ 2.56.1.
  • You run @andrea9293/mcp-documentation-server ≤ 1.13.0 (CVE-2026-54504) — its Web UI/API binds 0.0.0.0:3080 with no authentication; upgrade to ≥ 1.13.1 or bind to 127.0.0.1.
  • You run n8n-mcp < 2.57.4 in multi-tenant HTTP mode (CVE-2026-55608) — an authenticated tenant may still reach default-scope workflow-version backups; upgrade to ≥ 2.57.4.
  • You run HashiCorp terraform-mcp-server 0.2.1–1.0.0 (CVE-2026-14869 / -16496 / -16498) — unauthenticated SSRF plus two credential-reuse bugs across stateful/stateless modes; upgrade to ≥ 1.1.0 and rotate the Terraform token the server was configured with.
  • You run mcp-server-kubernetes before 3.6.0 / 3.7.0 (CVE-2026-46519 / CVE-2026-47250) — your ALLOWED_TOOLS-style restrictions are cosmetic, and log-processing workflows can leak kubeconfig bearer tokens; upgrade to ≥ 3.7.0 and rotate any operator kubeconfig tokens used with the server.
# Find MCP servers configured in your tools
cat ~/.cursor/mcp.json 2>/dev/null
cat ~/.windsurf/mcp.json 2>/dev/null
cat ~/.config/claude/*.json 2>/dev/null | grep -A2 mcp
ls ~/Library/Application\ Support/Claude/ 2>/dev/null

# Audit network-facing MCP exposure (a tool surface, not a default)
lsof -iTCP -sTCP:LISTEN -P -n 2>/dev/null | grep -iE 'mcp|model-context'

If you are affected

  1. Remove any MCP server you don't actively use. Each is attack surface.
  2. Update Microsoft Azure MCP server if you run it (CVE-2026-26118 + CVE-2026-32211); until patched for the latter, put it behind network ACLs / a reverse proxy that enforces auth.
  3. Update mcp-atlassian to ≥ 0.17.0 (MCPwnfluence, CVE-2026-27825/-27826); never expose its HTTP transport on 0.0.0.0 without an auth proxy. Pluto Security ships a detection/auto-update script.
  4. Update nginx-ui to ≥ 2.3.4 (CVE-2026-33032 / MCPwn), or add middleware.AuthRequired() to /mcp_message and set the IP allowlist to deny-all.
  5. Update @mcpjam/inspector to ≥ 1.4.3 (CVE-2026-23744) and never run an MCP inspector/dev tool bound to 0.0.0.0; keep it on 127.0.0.1. 5a. For aws-mcp-server (CVE-2026-5058 / -5059): treat as unfixed-in-the-wild. Remove from any reachable network path; restrict to loopback; rotate AWS credentials that were exposed to the host. Track ZDI-26-245 / -246 for the vendor patch. 5b. Update n8n-mcp to ≥ 2.47.4 (CVE-2026-39974). Until upgraded, block egress from the MCP host to cloud IMDS endpoints (169.254.169.254, metadata.google.internal, etc.) and restrict AUTH_TOKEN to trusted callers. 5c. Update fast-mcp-telegram to ≥ 0.19.1 (CVE-2026-52830). If you can't upgrade immediately, disable the default/legacy session file or move it outside the token-verifier's reachable path prefix, and don't expose the server's HTTP transport off-host. 5d. Update n8n-mcp to ≥ 2.56.1 (CVE-2026-54052) if you run multi-tenant HTTP mode; the update includes a migration that isolates and clears previously un-scoped backups. Rotate any credential references that were embedded in workflow-version snapshots readable by other tenants. 5e. Update @andrea9293/mcp-documentation-server to ≥ 1.13.1 (CVE-2026-54504), or at minimum bind its Web UI/API to 127.0.0.1 instead of 0.0.0.0 until you can upgrade. 5f. Update n8n-mcp to ≥ 2.57.4 (CVE-2026-55608) if you run multi-tenant HTTP mode; this is on top of the ≥ 2.56.1 upgrade for CVE-2026-54052 above. 5g. Update HashiCorp terraform-mcp-server to ≥ 1.1.0 (CVE-2026-14869 / -16496 / -16498) and rotate the Terraform API token the server held, since the SSRF could have exfiltrated it before you patched. 5h. Update mcp-server-kubernetes to ≥ 3.7.0 and rotate any kubeconfig bearer tokens used with it (CVE-2026-46519 / CVE-2026-47250); don't rely on ALLOWED_TOOLS-style env vars as a security boundary until confirmed patched.
  6. For Apache Doris MCP: apply the patch + the CVE tracker recommendations.
  7. For Alibaba RDS MCP: since Alibaba declined to patch, do not deploy without an isolating proxy that filters MCP messages.
  8. Do not expose stdio MCPs to network sockets. If you've wrapped one with a proxy / HTTP gateway, audit the proxy's input validation.
  9. Run MCP servers as their own unprivileged user, in a container with read-only credentials, on a host with strict egress allowlists.

The OX Security framing

OX Security calls this "The Mother of All AI Supply Chains" — making the case that the MCP standard's permissive trust posture is a systemic risk, not an implementation bug. Anthropic disagrees, arguing the protocol assumes explicit user trust in installed servers.

Practically, both can be right. The protocol is what it is. Defenders must treat MCP installation as equivalent to npm install -g of arbitrary code — because that's what it functionally is. → prevention/mcp-hygiene.md

Prevention

→ prevention/mcp-hygiene.md → prevention/agent-sandboxing.md

Sources