AI
Same-Origin Policy and DNS Rebinding: The 19-Year-Old Bug
Same-origin policy prevents JavaScript from domain A calling domain B. It checks port, scheme, and protocol. Simple requests – GET, HEAD, POST with form content types – bypass CORS preflight. Attackers use DNS rebinding: a malicious website loads script, then a DNS server changes that domain’s IP from public to localhost. The script now talks to a local server. NCC Group’s Singularity of Origin framework automates this. The newer multiple-answers method completes the rebind in 3 seconds. This bug has been open in Mozilla’s Bugzilla for 19 years.
MCP Servers: Why the Default Is Insecure
The Model Context Protocol standardizes AI tool communication over HTTP JSON-RPC. The specification explicitly requires origin header validation to prevent DNS rebinding. The official TypeScript SDK disables that protection by default for backwards compatibility. Most servers leave it disabled. Leitschuh built a custom UI over NCC Group’s Singularity that lists MCP tools, prompts, and resources over DNS rebinding. With one malicious website visit, an attacker gains full control over any MCP server running on the user’s machine.
Consequences: Google, Docker, and Paychecks
Google OSS-Fuzz’s MCP server exposed a remote code execution endpoint – Leitschuh popped a calculator after DNS rebind. Google Cloud Run, GKE, and GenAI Toolbox each earned $200 bounties. Docker’s MCP gateway claimed protection but remained vulnerable over streamable HTTP; Docker awarded a t-shirt and CVE. AWS Labs’ MCP server exposed the full AWS CLI. Anthropic paid $1,500 for vulnerabilities across all SDKs. Total: $2,100 plus a t-shirt.
Current Protections and the Long Road
Anthropic added conformance tests for tier-1 SDKs 1 SDKs – TypeScript, Python, C# – that require DNS rebinding protection enabled by default. Tier 2 (Java, Rust, Swift) not yet verified. Chrome and Edge now show a permission prompt for local network access (Private Network Access). Firefox and Safari do not. Chrome rolled back PNA in 2022 after breaking existing sites; the current prompt rolled out June 2025. Leitschuh has pushed for a prompt since his 2019 Zoom vulnerability. The browser fix remains incomplete.
Q&A
Are most developers safe because VS Code uses stdio for MCP servers? Yes, stdio avoids HTTP exposure, but companies shipping HTTP-based MCP servers (via localhost) are vulnerable. ▶ Watch (32:44)
What are the legacy reasons this browser behavior still exists? The original web model did not distinguish private from public networks; browsers now have to retrofit boundaries. Simple requests and CORS were designed for different threats. ▶ Watch (36:20)
Given MCP spec requires unauthenticated endpoints to list tools, will that lead to more vulnerabilities? It depends on whether those endpoints are hardened in SDKs. If every implementer must roll their own, mistakes scale. ▶ Watch (38:28)
Why has Mozilla not fixed this despite it being open source? Differing opinions on the fix; companies rely on the current behavior to avoid a permission prompt that breaks their use case. ▶ Watch (40:08)
Notable Quotes
“without these protections, attackers could use DNS rebinding to interact with local MCP servers remote websites.” Jonathan Leitschuh · ▶ Watch (17:36)
“DNS rebinding protection is disabled by default for backwards compatibility.” Jonathan Leitschuh · ▶ Watch (18:08)
“Pops and calculator. Hey.” Jonathan Leitschuh · ▶ Watch (20:22)
Key Takeaways
- DNS rebinding bypasses same-origin policy and exploits localhost servers through the browser.
- MCP servers using HTTP transport are vulnerable unless origin validation is explicitly enabled.
- Browser-level fixes (PNA prompts) remain incomplete and not adopted by all vendors.
About the Speaker(s)
Jonathan Leitschuh is an open source software security researcher and self-described Vulnerability Janitor. He was the inaugural Dan Kaminsky Fellow at HUMAN Security and later led research for OpenSSF’s Alpha-Omega project. He is best known for his 2019 Zoom zero-day disclosure.