CVE-2026-35568: DNS Rebinding Vulnerability in MCP Java-SDK Server Transport Layer

The Model Context Protocol (MCP) Java SDK provides the core infrastructure for developing Java-based MCP clients and servers. These servers expose JSON-RPC endpoints over Server-Sent Events (SSE) or HTTP servlets to facilitate tool execution and context retrieval for AI models. Prior to version 1.0.0, the SDK's server implementation contained a critical design flaw involving the omission of origin validation on incoming HTTP requests.

This vulnerability, tracked as CVE-2026-35568 (and GHSA-8jxr-pr72-r468), is classified under CWE-346 (Origin Validation Error) and CWE-350 (Reliance on Reverse DNS Resolution for a Security-Critical Decision). The affected component is the io.modelcontextprotocol.sdk:mcp-core package, specifically within the server transport layer responsible for handling incoming connections.

Because the SDK failed to enforce the mandatory origin checks required by the MCP specification, local MCP servers became susceptible to DNS rebinding attacks. A remote attacker could exploit a developer's web browser as an unauthenticated proxy, delivering unauthorized JSON-RPC payloads to an internal or locally bound MCP server instance.

The resulting security impact is highly dependent on the tools exposed by the specific MCP server implementation. If the server grants access to system-level tools, such as local file reading or shell command execution, this vulnerability escalates to arbitrary remote code execution on the host machine.

The Model Context Protocol specification (Section 2.0.1) mandates that all servers must validate the Origin header on incoming connections to prevent cross-origin exploitation. In affected versions of the MCP Java SDK, the transport layer processed incoming HTTP requests without verifying their source. The code responsible for JSON-RPC serialization and message routing acted in a security-agnostic manner, parsing and executing any syntactically valid request that reached the endpoint.

The vulnerability exists because the transport abstraction layer separated the HTTP request context from the JSON-RPC processing logic. When an HTTP request arrived at the SSE or Servlet endpoint, the underlying framework extracted the payload body but discarded or ignored the HTTP headers containing security metadata.

Consequently, the server possessed no mechanism to distinguish between a legitimate request originating from a locally trusted AI agent and a malicious request originating from a victim's web browser executing arbitrary JavaScript. The lack of standard Cross-Origin Resource Sharing (CORS) enforcement at the application layer further exacerbated the flaw.

DNS rebinding bypasses the network-level isolation of locally bound services (127.0.0.1). By omitting application-level Origin validation, the MCP Java SDK implicitly trusted the browser's Same-Origin Policy (SOP). However, the SOP relies on domain names rather than IP addresses, making it inadequate for protecting local services against dynamically remapped DNS records.

The remediation implemented in version 1.0.0 required structural changes to the transport layer to propagate HTTP context to the security enforcement logic. The core fix introduces a mandatory ServerTransportSecurityValidator interface designed to evaluate the HTTP Origin and Host headers before establishing a transport connection.

// Vulnerable Implementation Pattern (Pre-1.0.0)
public void handleRequest(HttpServletRequest request, HttpServletResponse response) {
    // Headers are ignored; payload is passed directly to the JSON-RPC router
    String payload = extractBody(request);
    jsonRpcRouter.route(payload);
}

The vulnerable code above demonstrates the fundamental flaw: the transport handler blindly forwards the payload. The patched architecture, introduced in commit 4c1c3d8d5cee28eb985e04821cc727615063542a, mandates the use of an McpTransportContext object. This context encapsulates the transport metadata, ensuring that headers are available for validation.

// Patched Implementation Pattern (1.0.0)
public void handleRequest(HttpServletRequest request, HttpServletResponse response) {
    McpTransportContext context = new McpTransportContext(request.getHeaders());
    
    // Security validation occurs before routing
    if (!securityValidator.isValid(context)) {
        response.setStatus(HttpServletResponse.SC_FORBIDDEN);
        return;
    }
    
    String payload = extractBody(request);
    jsonRpcRouter.route(payload);
}

The newly implemented DefaultServerTransportSecurityValidator explicitly checks the Origin header against a localized allowlist. If the header is missing, malformed, or points to an untrusted domain, the connection is rejected. Additionally, the SDK maintainers migrated the Spring-specific web components (mcp-spring-webflux and mcp-spring-webmvc) to the Spring AI project, leveraging its built-in security defaults for CORS enforcement.

DNS rebinding relies on manipulating the browser's Same-Origin Policy (SOP) by rapidly changing the IP address associated with a domain name. An attacker registers a domain and configures its authoritative DNS server to serve records with a very low Time-To-Live (TTL).

When a victim visits the attacker's website, the browser resolves the domain to the attacker's web server, which serves a malicious JavaScript payload. This payload initiates a background process that waits for the initial DNS record's TTL to expire.

Simultaneously, the attacker's DNS server updates the record for the domain to point to 127.0.0.1 or another private network IP address corresponding to the victim's local MCP server. The malicious JavaScript then initiates HTTP POST requests or SSE connections to the domain. Because the domain name has not changed, the browser considers these requests to be within the same origin and allows them.

The local MCP server, running on 127.0.0.1, receives these requests. Because the SDK lacks Origin validation, the server processes the incoming JSON-RPC payloads. The attacker constructs a tools/call JSON-RPC message, instructing the local server to execute a specific tool with attacker-controlled parameters.

The vulnerability allows an unauthenticated remote attacker to execute arbitrary JSON-RPC commands on a locally running MCP server. Because MCP servers are explicitly designed to expose tools to AI agents, these endpoints frequently possess highly privileged capabilities.

If the server exposes tools for file system manipulation, shell command execution, or database querying, the attacker achieves full remote code execution or data exfiltration on the victim's machine. The attack operates entirely in the background, requiring only that the victim visit a web page controlled by the attacker while the local MCP server is running.

The CVSS 4.0 score of 7.6 reflects the high severity of the vulnerability. The attack vector is classified as Network (AV:N), with Low complexity (AC:L). Privileges Required is None (PR:N). The requirement for the victim to visit a malicious site results in a User Interaction rating of Passive (UI:P). Vulnerability Confidentiality and Integrity are both High (VC:H, VI:H) due to the potential for data theft and arbitrary execution via exposed tools.

The Attack Requirements (AT:P) metric is present because the exploitation strictly requires the local environment to have a running, vulnerable MCP server that exposes tools capable of altering the system state or accessing sensitive data. Servers that expose purely computational or read-only public data tools incur a lower practical impact.

The primary remediation for CVE-2026-35568 is upgrading the io.modelcontextprotocol.sdk:mcp-core dependency to version 1.0.0 or later. This release fundamentally restructures the transport layer to enforce strict origin validation and integrates the McpTransportContext to ensure security metadata is passed to all request handlers.

For systems where an immediate dependency upgrade is not feasible, administrators should deploy a reverse proxy (such as Nginx or HAProxy) in front of the local MCP server. The proxy must be configured to inspect incoming HTTP requests and strictly validate the Host and Origin headers, dropping any request that does not originate from an explicitly trusted local source.

Developers utilizing Spring framework integrations should migrate their transport modules to the Spring AI project, as directed by the SDK maintainers. Spring AI applies robust, default-deny security configurations for CORS and origin validation, which neutralizes the DNS rebinding attack vector at the framework level.

Finally, binding the MCP server exclusively to the local loopback interface (127.0.0.1) prevents external network access but does not mitigate DNS rebinding. Network isolation must be combined with strict application-level origin checks to ensure comprehensive protection against modern web-based exploitation techniques.