Security1 publisher2 min readPublished
Microsoft's DebugMCP 1.1.4 left an unauthenticated debugger port open to malicious webpages
Imperva found Microsoft's DebugMCP 1.1.4 let a malicious webpage run code on a developer's machine through an unauthenticated port 3001 listener. The fix reached 1.2.0 with no advisory, so finding exposed machines means checking installed extension versions.
The Watch · Security desk
What happened
- Imperva reported that DebugMCP 1.1.4 let a remote attacker run arbitrary code on a developer's machine once the developer visited a malicious webpage, with no further interaction.
- Installing the extension starts a server that listens on port 3001 with no authentication.
- DebugMCP used its own Express setup and skipped the host and origin header checks that the MCP SDK's helper registers automatically to block DNS rebinding.
- Maintainers fixed the flaw in commit 86776b2m with no version bump or advisory, and the fix is in DebugMCP 1.2.0 and later.
Compiled by The WatchSomething wrong?How this is made
Why it matters
- exposure An MCP server that starts on install and answers without authentication can be reached by pages its developer opens, so it belongs on the same inventory as any exposed network service.
- constraint With no advisory attached, tools that match on published advisories have nothing to flag. Finding vulnerable installs depends on reading the extension version on each machine.
- precedent The SDK's rebinding defence covers only servers built on its helper, so any MCP server with a hand-rolled Express setup can repeat the CVE-2025-53967 pattern DebugMCP matched.
- exposure Because the same one-click install works on GitHub Codespaces and OpenVSCode Server, hosted development environments need checking along with laptops.
DNS rebinding in MCP servers already had a library fix. At the end of 2025 Anthropic added a default defence, tracked as CVE-2025-66414 [5]. Version 1.24.0 of the MCP SDK introduced createMcpExpressApp, a preconfigured Express server that registers validateHostHeader and validateOriginHeader automatically. Imperva says the two checks together prevent DNS rebinding [5]. A server that configures Express by hand gets neither check unless its maintainer adds the middleware [6]. Imperva says DebugMCP's custom server was identical to the setup behind CVE-2025-53967 [7]. It calls DNS rebinding "a recurrent risk issue when it comes to MCP servers' development" [8].
A hostile page that gets through reaches the tool set Microsoft DevLabs built for AI agents such as GitHub Copilot, Cline, Cursor, Codex and Windsurf [1]. The start_debugging tool takes a fileFullPath argument and tells VS Code to launch a debugger session for that file [9]. "That's a file execution primitive," Imperva wrote [9]. The same list includes evaluate_expression, which evaluates an arbitrary expression in the debugger context [10].
Imperva published after its 90-day disclosure period ran out [12]. The post does not describe attacks in the wild, name an attacker, or give the date of the original report [2]. For now this is a research finding about a bug class, with no campaign attached. Imperva recommends updating to the latest version [14].
Updating closes the browser route [11]. Imperva says a second route exists apart from the network exposure. An LLM fed indirect prompt injection could be tricked into accessing a file outside VS Code's workspace trust, and according to Imperva the maintainers' fix does not address that [13].
What to watch
- Whether Microsoft publishes an advisory or CVE for DebugMCP, which would put the flaw into scanner feeds.
- Whether the maintainers close the prompt-injection path to files outside workspace trust that Imperva says the fix leaves open.
- More MCP servers found with custom Express setups missing host and origin validation, the pattern behind CVE-2025-53967 and this case.