Harden MCP HTTP endpoint + fix start_debugging hangs for Testing-API runners

[ozzafar]

Fixes (1) unauthenticated debugger access via 0.0.0.0 bind and DNS rebinding via missing Host header validation, both reported by MSRC against src/debugMCPServer.ts, and (2) two bugs in the start_debugging flow for VS Code Testing-API runners (notably dotnet test) where the tool would hang past a breakpoint hit and past clean test completion.

---

Part 1 — MSRC: Harden MCP HTTP endpoint

Background

The DebugMCP HTTP server exposes powerful, unauthenticated debugger primitives (evaluate_expression, start_debugging, …). MSRC reported two composable vulnerabilities:

• 603080 — LAN exposure. app.listen(this.port, callback) was called with no host argument, so Node bound to all interfaces (0.0.0.0). Any host on the same Wi‑Fi / co‑working LAN could POST /mcp and invoke evaluate_expression('__import__("os").system(...)') for RCE on the debuggee, or start_debugging against a UNC path.
• 611073 — DNS rebinding → RCE. Even with a loopback bind, a malicious page on attacker.example (short‑TTL DNS flipped to 127.0.0.1) can reach the local server via the victim's browser. The server didn't inspect the Host header, so the rebound request hit start_debugging with a UNC fileFullPath and spawned attacker‑controlled code under the victim's user. PoC video from the finder confirmed it in Firefox.

Fixes

• Bind to loopback by default. The HTTP server now binds to 127.0.0.1 instead of all interfaces, so it is unreachable from other hosts on the network.
• Reject non‑loopback Host headers. Requests whose Host header doesn't name a loopback address (localhost, 127.0.0.1, [::1], with or without port) are rejected with HTTP 403 before any MCP handler runs — neutralizing DNS‑rebinding attacks even if the bind is later widened.
• Reject non‑loopback Origin headers. When Origin is present (browser‑originated requests), it must also be loopback; absent Origin is allowed so non‑browser MCP clients keep working.
• Explicit opt‑in for LAN exposure. A new debugmcp.bindHost setting lets advanced users widen the bind, with a marketplace warning describing the risk and a startup log warning when the value is non‑loopback.
• Regression tests. New security test suite covers the loopback / IPv6 / port‑suffix / attacker / LAN cases for the header validators, asserts the server refuses TCP on a non‑loopback interface, and asserts live POST /mcp requests with attacker Host / Origin headers receive 403.
• Documented security model. README now describes the loopback‑only default, the opt‑in bindHost, and the Host/Origin allow‑list, so the documented contract matches the implementation.

Manual repro against the fixed build

Rebinding-style request — now rejected:

curl -i -X POST "http://127.0.0.1:3001/mcp" \
  -H "Host: attacker.example" \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","id":1,"method":"tools/list"}'
→ HTTP/1.1 403 Forbidden
{"jsonrpc":"2.0","error":{"code":-32000,"message":"Forbidden: Host header is not a loopback address"},"id":null}

LAN-style probe — connection now refused:

nmap -p 3001 <your-LAN-IP>
→ 3001/tcp closed

---

Part 2 — Fix start_debugging hangs for Testing-API runners (e.g. dotnet test)

Background

When start_debugging is called with a testName, the handler routes through VS Code's Testing API (testing.debugAtCursor) so language extensions can manage runner-specific orchestration (e.g. dotnet test --filter <name> spawning a testhost.dll child process for xUnit/NUnit/MSTest). Two bugs were observed against a .NET xUnit project (Calculator.Tests):

1. Hang past breakpoint hit. debugTestAtCursor awaited vscode.commands.executeCommand('testing.debugAtCursor'), but that command's promise resolves only when the test run completes, not when the debug session starts. When the test paused on a breakpoint, the await blocked the handler forever — the readyPromise had already resolved 'stopped' but the handler never reached await readyPromise. The MCP tool only returned when something external (e.g. the next MCP request) caused the run to wrap up.
2. Hang past clean completion. When the test ran to completion without pausing, onDidTerminateDebugSession did not reliably fire for both the parent and testhost child sessions in time, so waitForDebugSessionReady ran out the configured timeout (default 180s) even though the test was clearly done.

Fixes

• Decouple readiness from test-run completion. IDebuggingExecutor.debugTestAtCursor now returns { started, runComplete }. The implementation no longer awaits testing.debugAtCursor; it surfaces the command's promise so the caller can use it as an independent "test run finished" signal. Dispatch errors are still surfaced (logged) via .catch.
• Race readyPromise against runComplete in the handler. handleStartDebugging now does Promise.race([readyPromise, runComplete.then(() => 'terminated')]) for the test path. A breakpoint hit returns immediately as 'stopped'; a clean run returns immediately as 'terminated'. The configured timeout is no longer a wait floor for either case.
• Surface coreclr no-build / missing-assembly errors clearly. The launch-config branch already threw a descriptive error when no built DLL was found; this PR's tests guard the contract.

Regression matrix tests — src/test/startDebuggingMatrix.test.ts

44 new fully‑mocked tests covering both code paths × four scenarios × seven languages. The mocks use deferred<T>() so each test deterministically controls when readyPromise and runComplete settle — no timers, no flakes.

Scenario	Launch path (no testName)	Test path (with testName)
pause-hit	readyPromise → 'stopped' → "stopped at breakpoint"	breakpoint wins race against pending runComplete → "stopped at breakpoint" (guards bug #1)
clean-run	readyPromise → 'terminated' → "ran to completion"	runComplete wins against a never-settling readyPromise → "ran to completion" (guards bug #2)
launch-error	startDebugging → false → "Failed to start"	debugTestAtCursor throws → propagates "Could not locate test"
no-build	getDebugConfig throws → propagates "Could not find a built assembly" (C# only)	—

Languages covered: Python, JavaScript, TypeScript, Java, C#, C++, Go. Plus one race tie-breaker test ensuring a runComplete resolution after readyPromise → 'stopped' cannot retroactively change the outcome.

Test housekeeping

Removed stale compiled artifacts under out/test/ that had no corresponding .ts source (debugConfigurationManager.test.js and the e2e/ folder) — they referenced API surfaces removed in earlier refactors and accounted for all 20 previously failing tests. Full suite now: 66 passing, 0 failing.

---

Validation

• npm run compile ✅
• npm run lint ✅
• npm test ✅ — 66 passing / 0 failing (after Inno Setup mutex from a stuck CodeSetup-stable-* installer was cleared)

[github-actions]

✅ Extension Build Successful!

📦 VSIX artifact is ready for download

👉 View artifacts

Scroll down to the "Artifacts" section and download extension-vsix

To install: In VS Code, run Extensions: Install from VSIX... and select the downloaded file.