Researchers reported a critical issue in Microsoft’s DebugMCP (v1.1.4) where a developer could be tricked into visiting a malicious webpage and end up with attacker code running on their machine. The attack abuses a locally running, unauthenticated server on port 3001 plus DNS rebinding to send a single background request that triggers the debugger to fetch and execute a remote Python payload.
How the Attack Worked
This attack breakdown centers on DebugMCP, a debugging extension/server tied to VS Code workflows. After installation, the server automatically started and began listening on port 3001 without authentication. That alone would normally be contained by browser same-origin protections, but researchers used DNS rebinding, a technique that exploits how browsers cache DNS records, to get a malicious webpage's JavaScript to send a request that the browser treated as same-origin and delivered to the local service.
Once that request reached DebugMCP, it could pass an attacker-controlled UNC path into VS Code's debugging infrastructure. That infrastructure handed the path to the Python launcher, which reached out to an attacker-controlled SMB share and loaded a file. The file then executed under the victim's user context, all triggered by a single HTTP request and a webpage visit.
Why It Succeeded
Several conditions combined to make this a working drive-by attack:
- A locally running developer tool exposed a service without authentication.
- DebugMCP v1.1.4 operated in a stateless MCP mode, letting a single request invoke tooling without any session handshake.
- The debugging workflow accepted full file paths, including UNC paths, from an external request rather than restricting input to trusted local paths.
- No further user interaction beyond visiting the page was required, meaning normal browsing behavior was enough to trigger the chain.
What to Watch For
Defenders and developers should watch for signs that a local developer tool is being abused:
- Unexpected local services listening on unusual ports without authentication.
- Webpages initiating requests to localhost or unfamiliar ports.
- Debugger activity, console errors, or Python launches that the user did not start.
- Network calls to SMB shares that are not recognized or expected.
Building Resistance
Developer workstations deserve treatment as high-value targets, since a compromised machine can expose live credentials, source code, and trusted access to internal infrastructure. Organizations can reduce exposure by regularly auditing which servers are listening on loopback interfaces and by minimizing the number of local services exposed by developer tooling. Because malicious webpages can use techniques like DNS rebinding to reach local services, developers should treat unexpected links in chat, email, or tickets with caution, even when the destination looks like an ordinary webpage. Finally, keeping developer tooling updated matters even when fixes are shipped quietly, since unpatched extensions can retain powerful execution features that attackers can exploit through everyday browsing activity.
Key findings
- A remote attacker could get code execution by tricking a developer into visiting a malicious webpage (drive-by).
- The DebugMCP extension/server was described as automatically listening on port 3001 "without authentication" after installation.
- DNS rebinding is used so a webpage can send a request that reaches the victim’s localhost DebugMCP service.
- An attacker-controlled UNC path can cause the debugger workflow to fetch a Python script from an attacker SMB share and execute it under the victim user context.
- DebugMCP v1.1.4 was configured in a stateless MCP mode, allowing a single request to invoke tooling without a session handshake.
Who’s being targeted
- Commonly targeted roles: Developers, Engineering, DevOps, IT, Security Awareness.
- Affected industries: Software development, Technology, Any organization with developers using VS Code and AI coding tools.
- Attack channels: website.
- Impersonated: A legitimate-looking website domain controlled by the attacker (DNS rebinding), Local DebugMCP server / VS Code debugging workflow (abused by attacker).
Red flags to watch for
- Unexpected local service exposure: a developer tool "listening on port 3001 without authentication"
- A webpage initiating requests to localhost / unusual port 3001 behavior
- Debugger activity or console errors when the user did not start debugging
- Network calls to SMB shares you don’t recognize
- Unexpected Python/debugger launches
- A tool accepting full file paths (including UNC paths) from an external request
Frequently asked questions
What is the DebugMCP drive-by RCE issue?
It was a critical issue in DebugMCP version 1.1.4 where visiting a malicious webpage could let an attacker achieve arbitrary code execution on a developer's machine without any further user interaction.
How did the attack reach a local service through a browser?
The attacker used DNS rebinding, a technique that exploits how browsers cache DNS records, to make a webpage's request reach the victim's local DebugMCP service listening on port 3001.
Why were developers specifically targeted?
A compromised developer machine holds live credentials, source code, and trusted access to internal infrastructure, making it a high-value target for a single browsing event to lead to full compromise.
Has this issue been fixed?
Yes, the fix was included in version 1.2.0 and later, though it was shipped silently without a version bump or advisory.
Read the video transcript
You click a link to “review this page,” and a few seconds later, Calculator pops up on your laptop… you never ran it. That’s a drive‑by RCE using the VS Code DebugMCP extension. Once installed, it quietly starts a server on localhost port 3001 with no authentication. A malicious site uses DNS rebinding so the browser thinks http://evil.attacker.com:3001 is safe, but the request actually hits your local DebugMCP server. Because DebugMCP 1.1.4 runs in stateless MCP mode, that single background request can call start_debugging with an attacker UNC path. VS Code’s debugger then pulls a Python script from an attacker SMB share and runs it under your user account, no extra clicks, just loading the page. If you use VS Code, here’s the move: right now, open your extensions, search for DebugMCP, and either update it fully or disable it, especially if you see it listening on port 3001.