Attack Chain

1. Attacker hosts a malicious website with a DNS name configured to perform DNS rebinding.
2. Victim visits the attacker’s website, initiating the DNS rebinding attack.
3. The victim’s browser resolves the attacker’s domain to a loopback IP address (e.g., 127.0.0.1) or a private network IP.
4. The browser sends an HTTP request to the MCP server running on the victim’s machine, using the attacker’s malicious domain in the Host header.
5. The vulnerable rmcp server, lacking Host header validation prior to v1.4.0, accepts the request as if it originated from a trusted source.
6. The attacker’s website sends authenticated requests to the MCP server, leveraging existing credentials or sessions.
7. The attacker enumerates available tools and resources exposed by the MCP server.
8. The attacker invokes tools with malicious intent, potentially leading to file writes, shell execution, API calls, or other actions limited only by the server’s exposed functionalities, resulting in arbitrary code execution on the victim’s machine.

Impact

Successful exploitation of this vulnerability allows an attacker to enumerate and invoke any tool exposed by a locally-running rmcp-based MCP server, read resources and state accessible via the MCP session, and trigger side effects like file writes or shell execution. Given that MCP servers frequently run with user privileges and expose developer tooling, the practical impact can extend to arbitrary code execution on the victim’s machine. This vulnerability affects users running versions of the rmcp crate prior to 1.4.0.

Recommendation

• Upgrade to rmcp version 1.4.0 or later to incorporate the fix for CVE-2026-42559.
• If upgrading is not feasible, implement a reverse proxy (e.g., nginx, Caddy) in front of the MCP server and configure it to validate the Host header, as outlined in the advisory under “Workarounds for Unpatched Users.”
• Deploy the Sigma rule Detect Suspicious Host Header to identify potentially malicious requests targeting internal services.