From Debugging to Code Execution: RCE in Microsoft DevLabs’ DebugMCP?

Summary

Imperva Threat Research disclosed a critical remote code execution vulnerability in Microsoft DevLabs' DebugMCP, an open-source Model Context Protocol server that gives AI agents direct control over the VS Code debugger. In version 1.1.4 the server automatically starts and listens on loopback port 3001 without authentication, and a remote attacker who lures a developer to a malicious webpage could achieve arbitrary code execution on that machine in the background with no further user interaction.^[1]

The exploit chains several weaknesses: the start_debugging tool accepts an uncontrolled fileFullPath, Windows UNC paths let the debugger's Python launcher fetch a file from an attacker-controlled SMB share, the MCP transport runs in stateless mode so no session handshake is enforced, and the custom express server omits host/origin header validation, enabling DNS rebinding to bypass browser same-origin and local-network protections.^[1]

The maintainers fixed the issue via commit 86776b2, silently released as version 1.2.0 with no version bump or advisory. Imperva reported the issue on May 19, the fix shipped May 24, and public disclosure followed after the 90-day window on September 25. There is no evidence of in-the-wild exploitation or a named threat actor.^[1][4]

Attack chain

1. Victim visits attacker page: The attacker's domain initially resolves to the attacker's public IP; the victim's browser loads the initial malicious page content.^[1]
2. DNS rebinding: The domain is registered with a very short TTL (1-2 seconds). The page polls in a JavaScript loop until the browser re-resolves the name, at which point the attacker's DNS server returns 127.0.0.1, causing subsequent requests to target the victim's localhost.^[1]
3. Cross-origin request to local server: The attacker's JavaScript issues a fetch to the DebugMCP endpoint on port 3001. Because the browser considers the request same-origin after rebinding, it reaches the locally running DebugMCP server.^[1]
4. Stateless MCP tool invocation: Because DebugMCP configured the transport in stateless mode, validateSession is bypassed and a single request invokes the start_debugging tool with an attacker-controlled UNC file path.^[1][6]
5. Payload retrieval via UNC/SMB: DebugMCP passes the UNC path to VS Code's debugging infrastructure and the Python launcher, which reaches out to the attacker's publicly accessible SMB share and downloads the malicious Python script.^[1]
6. Code execution: The launcher passes the downloaded script to start_debugging, executing the attacker-controlled payload under the victim's user context; the benign PoC ran calc.exe.^[1]

Disclosure timeline

How it works

DebugMCP exposes a local MCP server on port 3001 without authentication. The start_debugging tool accepts a fileFullPath argument and instructs VS Code to launch a debugger session for that file, providing a file-execution primitive.^[1]

On Windows, a UNC path (\\SERVER\SHARE\path\to\file) allows DebugMCP to pass an attacker path to the debugger's Python launcher, which fetches the file from the attacker's SMB share and executes it under the victim's user context, overcoming the need to know a local executable path.^[1]

The MCP TypeScript SDK's StreamableHTTPServerTransport enforces the JSON-RPC initialize/initialized lifecycle via validateSession, but when sessionIdGenerator is undefined (stateless mode, as configured in v1.1.4) validateSession returns immediately without checks, so a single no-cors HTTP request can invoke a tool.^[1][6]

Anthropic's SDK v1.24.0 added createMcpExpressApp, which registers validateHostHeader and validateOriginHeader to prevent DNS rebinding (CVE-2025-66414), but DebugMCP used a custom express configuration lacking those middleware validations, allowing DNS rebinding to circumvent same-origin and local-network access protections.^[1][5][7]

Affected versions and patch status

Key takeaways

• AI-assisted development extensions that expose local execution primitives, filesystem access, and debugger control turn developer workstations into dense collections of unauthenticated automation endpoints that attackers can drive just as easily as trusted agents.^[1]
• The vulnerability was not sophisticated and reused known techniques (DNS rebinding, UNC/SMB payload loading, stateless MCP); the novelty is the rate at which capable, unvetted local MCP servers are deployed onto high-value developer machines.^[1]
• Compromising a developer machine grants an attacker live credentials, source code, cloud CLI sessions, SSH/GitHub tokens, and push access to production, making it a short path to production infrastructure.^[1]

Defensive actions

• Update DebugMCP to the latest available version (1.2.0 or later), which contains the fix shipped after 1.1.4.: The vulnerable code path in v1.1.4 enables unauthenticated RCE; the patched release closes it.^[1][4]
• Regularly audit which servers are listening on loopback interfaces.: Locally listening, unauthenticated MCP servers such as DebugMCP on port 3001 are reachable by malicious web content via DNS rebinding.^[1]
• Use authentication in MCP servers and enforce governance over which MCP servers run in the network, with the ability to remove them.: Unauthenticated local automation endpoints built for trusted agents are equally drivable by attackers who reach them.^[1]
• For MCP development, use middleware that enforces host/origin validation (such as createMcpExpressApp since SDK v1.23.0) and validate file path inputs, rejecting UNC paths and remote schemes before passing them to execution primitives.: Missing header validation enabled DNS rebinding and unvalidated UNC paths enabled remote payload loading via SMB.^[1][5]