MCPwned: Hacking MCP Servers with One Skeleton Key Vulnerability

MCPwned: Hacking MCP Servers with One Skeleton Key Vulnerability

Speakers: Jonathan Leitschuh, Software Engineer turned Security Researcher, Human Security

Conference: BSides SF

YouTube: https://www.youtube.com/watch?v=4_Om7f_2dro

Overview

Jonathan Leitschuh's talk, "MCPwned: Hacking MCP Servers with One Skeleton Key Vulnerability," delves into a critical and long-standing class of browser-based vulnerabilities that enable public websites to compromise locally running servers. Specifically, Leitschuh focuses on the Model Context Protocol (MCP) servers, which are increasingly prevalent in the era of AI and large language models (LLMs) as a standardized way for AI tools to interact with various enterprise systems like databases, Git repositories, and monitoring services. The talk highlights how a fundamental misunderstanding or oversight by developers regarding browser security models, coupled with insecure defaults in popular SDKs, creates a "skeleton key" vulnerability that attackers can exploit.

The core of the problem lies in the interaction between the browser's Same Origin Policy (SOP) and techniques like DNS rebinding, which allow malicious websites to bypass browser security controls and communicate with local services that developers assume are only accessible locally. Leitschuh demonstrates how this vulnerability, which has plagued browsers for nearly two decades, can lead to severe consequences, including remote code execution (RCE), data exfiltration, and privacy violations on a user's machine or within their private network. The research underscores the urgent need for developers to adopt secure configurations and for browser vendors to implement robust, sticky safeguards against these pervasive threats.

This talk is particularly relevant in today's landscape, where AI-powered applications frequently deploy local agents or services that utilize protocols like MCP. The ease with which these systems can be compromised, often due to default settings in SDKs that disable crucial security protections, presents a significant attack surface. Leitschuh's work serves as a stark reminder that even sophisticated technologies built for the future can inherit vulnerabilities rooted in the past, demanding a renewed focus on fundamental browser security principles from both developers and platform providers.

Background

▶ Watch: Speaker intro and research motivation (0:00)

Jonathan Leitschuh, a software engineer who transitioned into security research and was the inaugural Dan Kaminsky fellow at Human Security, has a long-standing fascination with locally running servers and attacks via the browser. His research is driven by the observation that developers frequently build and ship products containing local web servers that often operate with elevated permissions on the user's machine. When these local servers are vulnerable, they can be exploited to achieve significant compromise.

The foundational security mechanism in browsers designed to prevent cross-site interactions is the Same Origin Policy (SOP). The SOP dictates that JavaScript from one origin (defined by scheme, host, and port) cannot interact with resources from another origin. This prevents, for instance, a malicious website from accessing data on a user's banking website. However, the web's evolution introduced scenarios where cross-origin communication is desired, leading to mechanisms like Cross-Origin Resource Sharing (CORS). CORS distinguishes between pre-flighted requests (PUT, POST with complex bodies, DELETE), which trigger an OPTIONS request to the server to check for explicit permission, and simple requests (HEAD, GET, OPTIONS, TRACE, and POST with application/x-www-form-urlencoded, multipart/form-data, or text/plain content types). Simple requests are deemed "safe" and can bypass the pre-flight check, allowing them to be made cross-origin without explicit server consent, primarily for backward compatibility with pre-CORS web behaviors.

The critical insight for Leitschuh's research is that malicious websites can leverage these "simple requests" or more advanced techniques like DNS rebinding to interact with servers running on localhost or within a user's private network. In essence, the browser acts as a confused deputy, making requests on behalf of a public malicious site to a private resource that the user's browser can access directly. This is not a new vulnerability; a Bugzilla report dating back 19 years highlights attempts to mitigate these attacks, and MITRE's stance has historically been that this behavior is required by W3C standards, despite its abuse potential. Developers, however, are often unaware of this fundamental browser behavior.

Leitschuh provides a comprehensive history of such attacks:

• 2006: "Drive-by farming" exploited routers by reconfiguring DNS servers via simple HTML/JavaScript requests.
• 2015: Wi-Fi router exploits accessed private networks to steal credentials and reconfigure admin interfaces.
• 2016: Jordan Mily found a remote code execution in JetBrains IDEs by tricking a local web server into loading a malicious project from an SMB drive.
• 2016: Tavis Ormandy discovered RCE in Trend Micro's manager.
• 2018: A Princeton team demonstrated attacks against IoT devices on private networks.
• 2018: PortSwigger and Gareth Hayes built a PoC for intranet port scanning using timing differentials.
• 2019: Leitschuh himself found the Zoom webcam hijack vulnerability, which allowed websites to force users into video calls without permission, later found by Assetnote to enable RCE.
• 2019: Bill Dempkkey found an RCE in Dell Support Assistant.
• 2020: eBay was found to be port scanning user machines.
• 2024: Avy Luminsky discovered a 0.0.0.0 day exploit bypassing browser controls.
• Last year: Research revealed Facebook and Yandex Android apps used local servers to deanonymize users visiting websites with tracking pixels.
• 2025: Mr. Bra discovered an RCE in ASUS software.
• An Anthropic MCP Inspector RCE was also found.

DNS rebinding attacks are a particularly potent bypass of the SOP. They work by having a malicious DNS server initially resolve a malicious domain (e.g., attack.com) to a public IP address. The browser loads JavaScript from this public server. For subsequent requests to the same domain, the malicious DNS server then responds with a local or private IP address (e.g., 127.0.0.1 or a private network address). Crucially, the browser still believes it's talking to attack.com, thus adhering to the SOP, but the network traffic is now routed to the local or private server. These attacks can be surprisingly fast: "first then second with cache flooding" takes 15-45 seconds, while "multiple answers" can work in about 3 seconds. Leitschuh notes that NCC Group's Singularity of Origin is a powerful open-source framework (written in Go) for orchestrating such attacks, providing both a malicious web server and DNS server, complete with pre-built payloads.

The focus of this talk, Model Context Protocol (MCP) servers, represents a modern application of this old problem. MCP is a standard designed to allow AI models (like those from Claude, OpenAI, and Cursor) to securely and uniformly interact with external systems (databases, Git, Sentry). MCP communication primarily occurs over HTTP, often using JSON-RPC. A critical component for developers is the MCP Inspector, a debugging tool used to test and interact with MCP servers. The MCP specification itself includes a crucial security directive: "Servers must validate the origin header on all incoming connections to prevent DNS rebinding attacks. If the origin header is present, and invalid, servers must respond with an HTTP 403 forbidden." However, Leitschuh discovered that the most popular MCP SDK, the TypeScript SDK, explicitly disables this DNS rebinding protection by default for "backwards compatibility," leaving it to developers to manually enable it—a step frequently overlooked. This combination of a powerful protocol, a critical but disabled security feature, and developer unawareness sets the stage for "MCPwned."

Key Findings

▶ Watch: Simple requests bypass CORS pre-flights (4:00)

Jonathan Leitschuh's research uncovered a widespread and critical vulnerability pattern within the emerging ecosystem of Model Context Protocol (MCP) servers, primarily stemming from insecure default configurations and a pervasive lack of developer awareness regarding long-standing browser security bypasses. The key findings include:

1. Default Insecurity in MCP SDKs: The most popular MCP SDK, the TypeScript SDK, ships with DNS rebinding protection explicitly disabled by default (dnsRebindingProtection: false). Despite the MCP specification clearly mandating Origin header validation to prevent these attacks, this default setting makes a vast number of MCP server implementations inherently vulnerable to browser-based attacks.
2. Effective Exploitation via DNS Rebinding: Leitschuh demonstrated that DNS rebinding attacks, facilitated by tools like NCC Group's Singularity of Origin, are highly effective in bypassing the Same Origin Policy and establishing communication with local MCP servers. This allows malicious public websites to act as a confused deputy, making requests to private services on the user's machine or internal network.
3. Widespread Vulnerability Across Major Platforms: The research revealed that numerous MCP server implementations across various platforms and services were vulnerable, leading to significant security impacts. These included:

• Remote Code Execution (RCE): Demonstrated on test servers (e.g., "server everything MCP") and critical infrastructure like Google OSS-Fuzz, leading to arbitrary code execution (e.g., popping a calculator).
• Data Exfiltration and System Control: Vulnerabilities in Google Cloud Run, Google Kubernetes Engine (GKE), and Google Geni Toolbox allowed for arbitrary file uploads, access to full cluster data, log querying, and privileged database/HTTP calls within internal networks.
• API Exposure with Credentials: Apollo GraphQL instances connected to MCP servers could expose full GraphQL APIs with authentication, allowing attackers to make authenticated calls.
• AWS Infrastructure Compromise: Running an MCP server with AWS Labs exposed the full AWS CLI, allowing browser-based interaction with a developer's AWS infrastructure.

1. Misconceptions by Vendors: Even vendors like Docker, who claimed their Docker MCP Gateway prevented such attacks due to containerization, were found to be vulnerable when using transport streaming, highlighting a misunderstanding of the browser's ability to reach local services.
2. Browser Security Lag and Rollbacks: Despite the long history of these vulnerabilities, browser vendors have struggled to implement lasting fixes. Chrome's Private Network Access (PNA) initiative, aimed at introducing pre-flight requests and user prompts for local network access, was initially rolled back due to compatibility issues, demonstrating the deep-seated challenges in addressing this problem without breaking existing web functionality.
3. Anthropic's Proactive Remediation: Anthropic, a key player in the AI space, responded positively by introducing a tiered SDK system with conformance tests that now include checks for DNS rebinding protection. Their Tier 1 SDKs are now secured by default, setting a positive precedent for the industry.

In summary, Leitschuh's work exposed a critical blind spot in the security posture of modern AI systems, demonstrating how a "skeleton key" vulnerability, rooted in fundamental browser behaviors and exacerbated by insecure SDK defaults, can unlock a wide array of high-impact attacks against local and private network resources.

Technical Deep Dive

▶ Watch: History of localhost/private network attacks (5:00)

The technical foundation of the "MCPwned" vulnerability chain rests on the interplay of several web security concepts: the Same Origin Policy (SOP), the nuances of CORS simple requests, and the powerful bypass mechanism of DNS rebinding.

The Same Origin Policy is a cornerstone of browser security, designed to isolate documents and scripts from different origins. An origin is defined by the combination of scheme (e.g., http, https), host (e.g., example.com), and port (e.g., 80, 443). JavaScript from malicious.com cannot directly read data or make arbitrary requests to bank.com. However, the web's need for cross-origin communication led to CORS. While CORS introduced pre-flighted requests (for HTTP methods like PUT, DELETE, or POST with complex content types), which require an OPTIONS request to the server for explicit permission, it also preserved simple requests. These include GET, HEAD, OPTIONS, TRACE, and POST requests with specific, "simple" Content-Type headers such as application/x-www-form-urlencoded, multipart/form-data, or text/plain. Crucially, simple requests do not trigger a CORS pre-flight. This means a malicious website can send these types of requests to any IP address or port that the user's browser can reach, including 127.0.0.1 (localhost) or addresses within the user's private network, without the server's explicit consent via CORS headers.

This is where DNS rebinding elevates the threat. While simple requests enable some cross-origin communication, they are still bound by the domain name displayed in the browser's address bar. DNS rebinding cleverly subverts this. The attack proceeds in two phases:

1. Initial Connection: A user visits malicious.com. The attacker controls the DNS server for this domain. The DNS server initially resolves malicious.com to a public IP address (e.g., 5.6.7.8), which hosts the attacker's web server. The browser loads malicious JavaScript from this public server.
2. Rebinding: The JavaScript then attempts to make subsequent requests to malicious.com. Before these requests, the attacker's DNS server responds with a very short Time-To-Live (TTL) for the DNS record. When the browser attempts to resolve malicious.com again, the DNS server now provides a private IP address (e.g., 127.0.0.1 or 192.168.1.100). Because the domain name (malicious.com) remains the same, the browser's SOP is satisfied, but the underlying IP address has "rebound" to a local or private network resource. The malicious JavaScript, running under the malicious.com origin, can now directly interact with the locally running server.

Leitschuh highlighted two primary DNS rebinding strategies:

• First then second with cache flooding: This involves stuffing multiple DNS records into the response to fill the browser's DNS cache, forcing a new lookup after the TTL expires. This technique typically takes 15-45 seconds.
• Multiple answers: A faster method that provides both the public and private IP addresses in a single DNS response, allowing the browser to eventually try the private IP. This can achieve rebinding in approximately 3 seconds.

The practical weaponization of DNS rebinding is often facilitated by frameworks like NCC Group's Singularity of Origin. This tool, written in Go, provides both a malicious web server (hosting the JavaScript payload) and a malicious DNS server, integrated to orchestrate the rebinding attack. It also comes with a library of pre-built attack payloads for various vulnerable services.

Model Context Protocol (MCP) servers are particularly susceptible to these attacks. MCP aims to standardize how AI tools interact with external systems, often using JSON-RPC over HTTP. A key component of the MCP ecosystem is the MCP Inspector, a local web-based debugging tool for interacting with MCP servers. The MCP specification explicitly states: "Servers must validate the origin header on all incoming connections to prevent DNS rebinding attacks. If the origin header is present, and invalid, servers must respond with an HTTP 403 forbidden." This crucial protection is designed to prevent requests from unexpected origins (like malicious.com after rebinding) from being processed.

However, Leitschuh discovered that the widely used TypeScript SDK for building MCP servers disables this vital protection by default (dnsRebindingProtection: false). This default setting, chosen for "backwards compatibility," means that developers using the SDK must explicitly enable Origin header validation. As demonstrated by the widespread vulnerabilities, this manual step is frequently overlooked, leaving MCP servers exposed. An attacker can use DNS rebinding to make simple POST requests (which are common for JSON-RPC) to the local MCP server, bypassing browser security and directly interacting with its exposed functionalities. This allows for querying tools, making tool calls, uploading files, accessing databases, and even executing arbitrary code, leveraging the browser as an unwitting proxy.

Demo / Proof of Concept

▶ Watch: JetBrains IDE RCE via local web server (7:50)

Jonathan Leitschuh provided compelling demonstrations and identified numerous real-world vulnerabilities, showcasing the power of DNS rebinding against MCP servers and other local services. His proof-of-concept (PoC) attacks utilized NCC Group's Singularity of Origin framework, often combined with custom payloads and, in some cases, a bespoke MCP Inspector user interface built on top of Singularity.

1. Server Everything MCP: Leitschuh first targeted "server everything MCP," a test server designed to exercise all features of the MCP protocol. Using Singularity of Origin with a custom payload, he demonstrated the ability to extract all environment variables from the running MCP server. This initial demo, using the "first then second with cache flooding" DNS rebinding strategy, required an 8x speed-up in the video due to its 15-45 second duration.

1. Google OSS-Fuzz: A more critical finding involved Google OSS-Fuzz, which incorporated an MCP server exposing a remote code execution (RCE) endpoint. Leveraging the faster "multiple answers" DNS rebinding strategy (achieving rebinding in approximately 3 seconds), Leitschuh successfully triggered an RCE, demonstrating it by making the calculator application pop up on the target machine. Google acknowledged this vulnerability, awarding it "experimental out of scope."

1. Custom MCP Inspector UI: Recognizing the utility of the standard MCP Inspector debugging tool, Leitschuh built a shiny user interface on top of Singularity of Origin. This custom UI allowed him to connect to a target MCP server via DNS rebinding and interact with it, listing its available tools, prompts, resources, and logs—effectively providing a remote debugging interface for compromised local servers.

1. Google Cloud Run: Using his custom MCP Inspector, Leitschuh demonstrated a vulnerability in Google Cloud Run instances that exposed the ability to upload arbitrary files. By connecting to the Cloud Run MCP server via DNS rebinding, he could list its capabilities and tools, showcasing unauthorized access to file upload functionalities. Google awarded him $200 for this finding.

1. Google Kubernetes Engine (GKE): Similarly, Google Kubernetes Engine (GKE) instances with exposed MCP servers allowed for the dumping of full cluster data and querying of logs. The DNS rebinding attack granted access to sensitive operational data, for which Google also awarded $200.

1. Google Geni Toolbox: This developer tool connects MCP servers to databases and allows them to make HTTP calls to specified endpoints. Leitschuh highlighted this as a "juicy target," as a successful DNS rebinding attack could enable an attacker to make arbitrary SQL calls to connected databases or perform HTTP calls within the developer's internal network, effectively inheriting the developer's privileges. This earned another $200 from Google.

1. Apollo GraphQL: Leitschuh noted that Apollo GraphQL implementations, when hooked up to MCP servers, could expose their full GraphQL API with credentials. A DNS rebinding attack would allow authenticated calls to the GraphQL API, potentially leading to significant data access or manipulation.

1. Docker MCP Gateway: Docker had published a blog post claiming their MCP Gateway prevented such attacks, arguing that the browser couldn't reach a Docker container. Leitschuh accepted this as a challenge and successfully demonstrated that if the Docker MCP Gateway was running with transport streaming, it was indeed vulnerable to DNS rebinding. This vulnerability was assigned a CVE number, and Docker awarded him a t-shirt and some swag.

1. AWS Labs: A particularly impactful finding was with AWS Labs. If a developer was running an MCP server with AWS Labs on their local machine, a DNS rebinding attack could expose the full AWS CLI. This meant an attacker could call into all of the developer's AWS infrastructure via their browser, potentially leading to widespread cloud resource compromise.

These demonstrations collectively illustrate the severe implications of insecure MCP server configurations and the persistent threat posed by DNS rebinding, showcasing how a single "skeleton key" vulnerability can unlock a multitude of sensitive systems and data.

Defensive Implications

▶ Watch: Intranet port scanning proof of concept (8:50)

The "MCPwned" research highlights critical defensive measures that must be adopted by both developers and browser vendors to mitigate the long-standing threat of browser-based attacks on local and private network services.

For Developers and SDK Maintainers:

1. Enable DNS Rebinding Protection by Default: This is the most crucial takeaway. SDKs, especially for protocols like MCP, must enable Origin header validation by default. The TypeScript SDK's default of dnsRebindingProtection: false is a severe security misstep. Developers should immediately ensure this setting is true in their MCP server implementations. Anthropic's move to a tiered SDK system with conformance tests that enforce DNS rebinding protection for Tier 1 SDKs is an excellent model for other vendors to follow.
2. Prioritize Standard IO: Whenever possible, use Standard IO for inter-process communication with local services instead of HTTP-based channels. Standard IO is not exposed over network ports and is therefore immune to HTTP-based browser attacks like DNS rebinding.
3. Validate All Incoming Connections: For any local web server, rigorously validate the Origin header for all incoming HTTP requests. If the Origin header is present and does not match expected values (e.g., null for direct file access, or specific trusted origins for legitimate cross-origin communication), the server should respond with an HTTP 403 Forbidden error.
4. Least Privilege Principle for MCP Servers: Curate and limit the capabilities exposed by MCP servers. Do not expose an entire API surface if only a subset of functionalities is needed. This reduces the attack surface and potential impact if a server is compromised.
5. Implement CSRF Tokens: While Origin validation helps against DNS rebinding, other simple request attacks like Cross-Site Request Forgery (CSRF) remain a concern. For any web application or local web server that processes state-changing requests, robust CSRF token implementation is essential.
6. Developer Education: There is a significant knowledge gap among developers regarding browser security models, particularly the nuances of simple requests and DNS rebinding. SDK documentation and development guides must explicitly educate developers on these risks and the necessary protections.

For Browser Vendors:

1. Persist with Private Network Access (PNA): Browser vendors, particularly Chrome and Edge, must continue their efforts to implement and roll out the Private Network Access (PNA) specification. This involves introducing pre-flight requests for all local network access and, critically, explicit user prompts. While past rollbacks due to compatibility issues are a concern, the security benefits outweigh the integration challenges.
2. Improve User Prompts: When PNA prompts are implemented, they must be clear, concise, and effectively communicate the security implications of granting a public website access to local network resources. Users need to understand that this is akin to granting camera or microphone access, as it can lead to similar levels of compromise depending on the vulnerable local service.
3. Standardize and Enforce Controls: Work towards a unified approach across browsers (Firefox, Safari, Chrome, Edge) to address these vulnerabilities. The current disparity in support for PNA (Chrome/Edge prompt, Firefox/Safari do not) creates an uneven security landscape.

In conclusion, defending against "MCPwned" and similar attacks requires a multi-layered approach. Developers must proactively secure their local services by enabling protections, limiting exposure, and understanding browser security. Browser vendors must continue to evolve their security models to provide robust, user-centric safeguards against these persistent and often high-impact threats.

Key Takeaways

• DNS rebinding remains a potent and widely misunderstood attack vector: This long-standing browser vulnerability allows malicious public websites to bypass the Same Origin Policy and interact with local or private network services, often leading to severe compromise.
• Insecure defaults in SDKs are a primary culprit: Popular SDKs, like the TypeScript SDK for MCP, explicitly disable critical DNS rebinding protections by default, leaving numerous implementations vulnerable unless developers manually enable them.
• MCP servers are high-value targets: As standardized interfaces for AI tools to interact with databases, Git, and other critical systems, compromised MCP servers can lead to remote code execution, data exfiltration, and full control over internal network resources or cloud infrastructure (e.g., AWS CLI exposure).
• Browser security is slowly catching up but faces significant challenges: Initiatives like Chrome's Private Network Access (PNA) aim to introduce user prompts and pre-flights for local network access, but backward compatibility issues have caused rollbacks, highlighting the difficulty in fixing deep-seated web behaviors.
• Developers must prioritize Origin header validation and Standard IO: For any local service exposed over HTTP, rigorous validation of the Origin header is non-negotiable. Where possible, using Standard IO for local communication bypasses these HTTP-based attack vectors entirely.
• Industry collaboration and standardized security are crucial: Anthropic's adoption of a tiered SDK system with mandatory DNS rebinding conformance tests is an excellent example of how vendors can proactively secure their ecosystems and educate developers.

About the Speaker(s)

Jonathan Leitschuh is a distinguished security researcher with a background as a software engineer. He was honored as the inaugural Dan Kaminsky fellow at Human Security, a testament to his impactful contributions to the field of cybersecurity. Leitschuh is also recognized as a GitHub Star and previously served as a GitHub Security Ambassador. His research often focuses on the intersection of browser security and locally running applications, a domain where he has uncovered significant vulnerabilities. Notably, he is credited with discovering the 2019 Zoom webcam hijack vulnerability, which garnered international attention, and has continued to expose critical flaws in various systems, as highlighted in his "MCPwned" presentation.