What is the CVSS score of CVE-2026-42559?

CVE-2026-42559 has a CVSS 3.1 base score of 8.8 (High). CVSS vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H. EPSS exploitation probability: 0.0%.

Which versions of rmcp are affected by CVE-2026-42559?

CVE-2026-42559 is a DNS rebinding vulnerability in the rmcp Rust crate that allows attackers to execute arbitrary code on local MCP servers through malicious websites, affecting any organization…. A patch is available.

Is there a public PoC exploit available for CVE-2026-42559?

Yes, a public proof-of-concept exploit is available for CVE-2026-42559. Prioritise patching immediately. EPSS: 0.0%.

How to fix or mitigate CVE-2026-42559?

Within 24 hours: Identify all internal projects and dependencies using rmcp Rust crate versions prior to 1.4.0 via dependency scanning tools (cargo-tree, SBOM analysis). Within 7 days: Upgrade rmcp to version 1.4.0 or later in all affected projects; prioritize services exposing Streamable HTTP server transport. Within 30 days: Implement Host header validation controls as documented in PR #764 for any custom HTTP server implementations; conduct code review of MCP server configurations to confirm loopback-only allowlist defaults are enforced.

rmcp CVE-2026-42559

EUVD-2026-30292 HIGH

Origin Validation Error (CWE-346)

2026-05-06 https://github.com/modelcontextprotocol/rust-sdk

GHSA-89vp-x53w-74fx

Python RCE Java Nginx

8.8

CVSS 3.1 · GitHub Advisory

Severity by source

GitHub Advisory PRIMARY

8.8 HIGH

AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H

Primary rating from GitHub Advisory · only source for this CVE.

CVSS VectorGitHub Advisory

CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H

Attack Vector

Network

Attack Complexity

Low

Privileges Required

None

User Interaction

Required

Scope

Unchanged

Confidentiality

High

Integrity

High

Availability

High

Lifecycle Timeline

Source Code Evidence Fetched

May 06, 2026 - 22:39 vuln.today

Analysis Generated

May 06, 2026 - 22:39 vuln.today

CVE Published

May 06, 2026 - 21:55 nvd

HIGH 8.8

DescriptionGitHub Advisory

Summary

Prior to version 1.4.0, the rmcp crate's Streamable HTTP server transport (crates/rmcp/src/transport/streamable_http_server/) did not validate the incoming Host header. This allowed a malicious public website, via a DNS rebinding attack, to send authenticated requests to an MCP server running on the victim's loopback or private-network interface - violating the MCP specification's transport security guidance.

Impact

An attacker who convinces a victim to visit a malicious page can:

Enumerate and invoke any tool exposed by a locally-running rmcp-based MCP server.
Read resources, prompts, and any state accessible via the MCP session.
Trigger side effects (file writes, shell execution, API calls, etc.) limited only by what tools the victim's server exposes.

Because MCP servers frequently run with the user's privileges and expose developer tooling (filesystems, shells, browser control, language servers, etc.), the practical impact can extend to arbitrary code execution on the victim's machine.

Affected Versions

rmcp < 1.4.0 - all prior releases of the Streamable HTTP server transport. Non-HTTP transports (stdio, child-process) are not affected.

Patched Versions

rmcp >= 1.4.0 (current: 1.5.1).

Patch

Fixed in PR #764 (commit 8e22aa2), released as v1.4.0 on 2026-04-09:

StreamableHttpServerConfig::allowed_hosts now defaults to a loopback-only allowlist: ["localhost", "127.0.0.1", "::1"].
All incoming HTTP requests pass through validate_dns_rebinding_headers(), which parses the Host header and returns HTTP 403 if the host is not on the allowlist.
Public deployments can configure an explicit allowlist via StreamableHttpService::with_allowed_hosts(...), or opt out (not recommended without an upstream reverse proxy that validates Host) via disable_allowed_hosts().

This fix validates the Host header only. Origin header validation is tracked as a defense-in-depth follow-up in #822 and is not required to block the DNS rebinding attack described here - the browser cannot forge the Host header sent to the rebound server.

Workarounds for Unpatched Users

Upgrade to rmcp >= 1.4.0.
If upgrade is not possible, place the MCP server behind a reverse proxy (e.g. nginx, Caddy) configured to reject requests whose Host header is not one of your expected hostnames.
Do not bind the MCP server to 0.0.0.0 without such a proxy.

Resources

PR: https://github.com/modelcontextprotocol/rust-sdk/pull/764
Issue: https://github.com/modelcontextprotocol/rust-sdk/issues/815
Follow-up (Origin validation): https://github.com/modelcontextprotocol/rust-sdk/issues/822
MCP transport security guidance: https://modelcontextprotocol.io/specification/2025-06-18/basic/transports#security-warning

Related advisories (same class of vulnerability)

TypeScript SDK: GHSA-w48q-cv73-mx4w
Python SDK: GHSA-9h52-p55h-vw2f
Go SDK: GHSA-xw59-hvm2-8pj6
Java SDK: GHSA-8jxr-pr72-r468

AnalysisAI

DNS rebinding in rmcp Rust crate allows malicious websites to control local MCP servers and achieve arbitrary code execution through exposed developer tools. Fixed in version 1.4.0 via Host header validation with loopback-only default allowlist. The vulnerability affects Streamable HTTP server transport only (stdio and child-process transports unaffected). Vendor-released patch available (PR #764, commit 8e22aa2). Similar vulnerabilities patched across TypeScript, Python, Go, and Java MCP SDKs indicate coordinated disclosure. CVSS 8.8 (network vector, low complexity, requires user interaction) reflects browser-mediated attack requiring victim to visit attacker site.

Technical ContextAI

The Model Context Protocol (MCP) provides structured communication between AI applications and external tools. The rmcp crate implements MCP in Rust, exposing a Streamable HTTP server transport for remote clients. Prior to 1.4.0, the HTTP server (crates/rmcp/src/transport/streamable_http_server/) accepted requests without validating the HTTP Host header against an allowlist. This violates the fundamental defense against DNS rebinding attacks, where an attacker-controlled domain initially resolves to a public IP, then rebinds to 127.0.0.1 or a private IP. The browser's same-origin policy allows the attacker's JavaScript to send authenticated requests to the rebound local endpoint. CWE-346 (Origin Validation Error) captures this class of flaw. The fix introduces validate_dns_rebinding_headers() which parses the Host header using http::uri::Authority, normalizes hostnames (case-insensitive, IPv6 bracket stripping), and rejects requests with HTTP 403 if the host is not on StreamableHttpServerConfig::allowed_hosts. The default allowlist restricts to loopback addresses (["localhost", "127.0.0.1", "::1"]), blocking cross-origin browser attacks while permitting local tool access. Public deployments must explicitly configure allowed_hosts via with_allowed_hosts() or deploy behind a reverse proxy that validates Host headers. The patch diff shows integration into the tower service layer, rejecting requests before they reach MCP handlers. Origin header validation (#822) is tracked separately as defense-in-depth but not required since browsers cannot forge Host headers during DNS rebinding.

RemediationAI

Upgrade rmcp to version 1.4.0 or later (current version 1.5.1) per vendor advisory at https://github.com/modelcontextprotocol/rust-sdk/security/advisories/GHSA-89vp-x53w-74fx. The fix was released on 2026-04-09 via PR #764 (https://github.com/modelcontextprotocol/rust-sdk/pull/764, commit 8e22aa2). Version 1.4.0 introduces StreamableHttpServerConfig::allowed_hosts defaulting to loopback-only (["localhost", "127.0.0.1", "::1"]) and rejects requests with non-allowlisted Host headers via HTTP 403. If immediate upgrade is not possible, deploy the MCP server behind a reverse proxy (nginx, Caddy, Apache) configured to reject requests whose Host header does not match expected hostnames-this delegates validation to the proxy layer but requires additional infrastructure and careful configuration to avoid bypass via proxy misconfiguration. Do not bind the MCP server to 0.0.0.0 or public interfaces without such a proxy, as this exposes the service to direct network attacks beyond DNS rebinding. Public deployments upgrading to 1.4.0+ must explicitly configure allowed_hosts via StreamableHttpService::with_allowed_hosts(["example.com", "api.example.com:8080"]) to match their production hostnames; the loopback-only default will block legitimate public traffic. Opting out via disable_allowed_hosts() is strongly discouraged unless an upstream proxy validates Host headers, as this re-introduces the vulnerability. Note that Origin header validation (issue #822) is tracked as future defense-in-depth but not required to block DNS rebinding.