The MCP Java SDK—used to build Model Context Protocol servers and clients—ships with a hardcoded wildcard CORS configuration in versions prior to 0.83.0, 1.0.1, and 1.1.1. Because the SDK allows requests from any origin by default, an attacker can trick a victim's browser into sending authenticated requests to an exposed MCP endpoint, stealing tokens or triggering unauthorized tool executions. This is CVE-2026-34237, rated high severity, and it deserves immediate attention from anyone running Java-based MCP servers.
How the Attack Works
Cross-Origin Resource Sharing (CORS) is a browser mechanism that decides whether a web page from evil.com can interact with a server on mcp-api.example.com. A secure server explicitly lists permitted origins in its Access-Control-Allow-Origin header. The vulnerable MCP Java SDK, however, sends Access-Control-Allow-Origin: * for every request, which tells the browser that any origin—including a malicious phishing page—is trusted.
The practical kill chain looks like this: an attacker hosts a malicious page that uses JavaScript to call the victim's local or remote MCP server. Because the browser sees the wildcard header, it permits the request and includes any cookies or basic-auth headers already stored for that target origin. If the MCP server exposes tools that query databases, file systems, or internal APIs, the attacker effectively gains a remote-control channel through the victim's browser session.
Real-World Implications for AI Agents
AI agents increasingly run as local or edge services that expose MCP endpoints to browsers, IDEs, and chat clients. Unlike traditional REST APIs, MCP servers often support long-lived tool sessions with broad permissions. A wildcard CORS policy collapses the entire browser same-origin boundary, letting malicious web pages invoke those tools directly.
Consider a coding assistant that exposes an MCP server on localhost. A developer visits a compromised documentation site, and that site silently calls the local MCP tool to read ~/.ssh/id_rsa or exfiltrate environment variables. Because the request originates from the browser, it may ride existing authentication cookies or session tokens. The result is not just data leakage but potential remote-code execution via tool chaining.
Defensive Measures
The immediate fix is to upgrade the MCP Java SDK to patched versions: 0.83.0, 1.0.1, or 1.1.1 or later. If you cannot upgrade immediately, override the CORS configuration explicitly rather than relying on defaults. Below is a Spring-style example that replaces the wildcard with an allow-list:
@Bean
public CorsConfigurationSource corsConfigurationSource() {
CorsConfiguration config = new CorsConfiguration();
config.setAllowedOrigins(List.of("https://trusted-app.example.com"));
config.setAllowedMethods(List.of("GET", "POST", "OPTIONS"));
config.setAllowedHeaders(List.of("Authorization", "Content-Type"));
config.setAllowCredentials(true); // never combine with wildcard origin
UrlBasedCorsConfigurationSource source = new UrlBasedCorsConfigurationSource();
source.registerCorsConfiguration("/**", config);
return source;
}
Additional hardening steps:
- Never pair Access-Control-Allow-Origin: * with Access-Control-Allow-Credentials: true. Browsers reject this combination in modern versions, but misconfigured legacy clients may still honor it.
- Run MCP servers behind a reverse proxy (nginx, Traefik, Envoy) that strips or overrides CORS headers, giving operators a centralized choke point.
- Validate the Origin header server-side even when CORS headers are correct. Reject requests whose origin does not match an explicit allow-list.
- Scope tokens and sessions narrowly. Use per-tool or per-session credentials that expire quickly, limiting the blast radius of a successful cross-origin request.
Detection and Monitoring
Detecting exploitation attempts relies on log inspection and browser telemetry. Look for:
- HTTP requests to MCP endpoints carrying an Origin header that does not match your allow-listed domains.
- Unusual tool invocation patterns from browser User-Agent strings, especially when the client IP belongs to a residential ISP rather than your infrastructure.
- Sudden spikes in OPTIONS preflight requests, which may indicate automated cross-origin probing.
If you use a Web Application Firewall or API gateway, add a rule that blocks POST or GET requests to /mcp/* paths when the Origin header is present and unrecognized.
Conclusion
CVE-2026-34237 is a configuration-level vulnerability with network-level consequences. A single hardcoded wildcard in the MCP Java SDK undermines the same-origin policy that keeps web applications isolated from each other. Upgrade to the patched versions, replace the default CORS policy with an explicit allow-list, and monitor your MCP endpoints for cross-origin abuse. The original disclosure is available at NVD CVE-2026-34237.
