The Java SDK for Model Context Protocol (MCP), specifically the io.modelcontextprotocol.sdk:mcp-core package, suffers from a DNS rebinding vulnerability in versions prior to 1.0.0. Attackers can exploit this to reach local or private-network MCP servers through a victim’s browser, impersonating a legitimate local AI agent and executing arbitrary tool calls.
This flaw stems from the absence of Origin header validation, which the MCP specification mandates. The spec’s transport section (version 2025-06-18) explicitly warns: “Servers MUST validate the Origin header on all incoming connections to prevent DNS rebinding attacks.” Without it, browsers tricked by DNS rebinding bypass same-origin protections, letting malicious sites probe and control your MCP endpoints.
How DNS Rebinding Works Here
DNS rebinding tricks a browser into resolving a domain—say, attacker.com—first to the attacker’s server (public IP), then, after a short TTL, to a private address like 127.0.0.1:8080 or 192.168.1.100:8080, where your MCP server runs. The browser treats requests as same-origin after rebinding because the domain matches, ignoring IP changes.
In MCP setups, servers handle tool calls from AI agents, like reading files, querying databases, or executing code. An attacker loads a malicious page on your device, triggers rebinding, and sends HTTP requests with forged origins. The vulnerable SDK accepts them, allowing tool invocations as if from a trusted local client. Spring AI escapes this because it enforces CORS and Origin checks by default; plain MCP-core does not.
Real-world context: MCP powers secure AI-tool integrations, often in dev environments where servers bind to localhost or LAN for low-latency agent ops. Adoption is growing with AI SDKs from Anthropic and others emphasizing local execution. But security lags— this vuln highlights how protocol specs don’t enforce compliance, leaving impls exposed.
Impact: Why Developers Should Act Now
Any user visiting a malicious site risks compromise if running an exposed MCP server. Attackers gain your agent’s tool access: imagine a phishing page silently emailing your files or running shell commands via AI tools. Private networks amplify this—office LANs, VPNs, or IoT setups become vectors.
Scale matters. MCP integrates with frameworks like LangChain or direct agent loops. A single vuln visit hands over control. No public exploits yet, but DNS rebinding kits exist on GitHub; pairing with AI hype makes targeted attacks likely. Fair point: only HTTP transports without proxies hit this, and fixed in 1.0.0. Still, thousands of devs use pre-1.0 via Maven Central—check your pom.xml.
Broader implications cut deep into AI security. Tool-calling agents promise power but expose endpoints. This echoes Web2 flaws like CORS misconfigs, but AI adds agency: attackers don’t just read data; they act. Expect copycats in other SDKs (Node.js, Python). Regulators eyeing AI risks will scrutinize such gaps.
Fixes and Hardening Steps
Upgrade to MCP-core 1.0.0 or later immediately—it adds Origin validation. Verify via Maven:
$ mvn dependency:tree | grep mcp-core
Short-term: Deploy a reverse proxy like Nginx. Configure it to reject bad Hosts/Origins:
server {
listen 8080;
server_name localhost; # Pin to expected host
location / {
if ($http_origin !~* "^https?://(localhost|127\.0\.0\.1|192\.168\.)") {
return 403;
}
proxy_pass http://127.0.0.1:8081; # Your MCP
}
}
HAProxy works similarly with acl rules. Prefer frameworks like Spring AI for built-in guards. Firewall localhost ports (e.g., ufw deny 8080 from WAN) and run servers on Unix sockets if possible—MCP supports them, dodging HTTP entirely.
Skeptically, no silver bullet: proxies add latency, upgrades demand testing. Audit all AI SDKs for spec compliance. In finance/crypto/tech stacks, where agents handle trades or keys, this isn’t hypothetical—it’s a breach waiting. Patch now; test origins manually with curl:
$ curl -H "Origin: https://evil.com" -X POST http://localhost:8080/tools/call
Returns 403 post-fix. Stay vigilant—MCP’s youth means more holes ahead.
