CVE-2026-107824: x64dbg MCP server exposes full debugger control without authentication
x64dbg-mcp-server before 1.1 served all debugger tools over HTTP/SSE on 0.0.0.0 with no auth (CVSS 4.0 9.3). Upgrade, then check every local MCP server for its bind address and authentication.
Act now
- Upgrade x64dbg-mcp-server to 1.1 Affects reverse-engineering and security workstations running the plugin. Advisories: GHSA-4478-h5jv-647m, GHSA-jgj3-97w2-9v9r.
- Find MCP servers listening beyond loopback Run ss -ltnp (Linux), lsof -iTCP -sTCP:LISTEN (macOS) or query your EDR for listeners on 9094/9095 and other MCP ports bound to 0.0.0.0.
In brief
- Affected: x64dbg-mcp-server before 1.1, ports 9094 (x64) and 9095 (x32), bound to 0.0.0.0 by default.
- Impact: attach to processes, read and write memory, write arbitrary files, from anywhere that can reach the port.
- Fix: upgrade to 1.1. Then audit all MCP servers on workstations for non-loopback binds and missing auth.
The issue
The community x64dbg-mcp-server plugin, which lets an AI client drive the x64dbg debugger over MCP, served every debugger tool over HTTP/SSE without authentication and listened on 0.0.0.0 by default: port 9094 for the x64 build and 9095 for x32. Anyone who could reach the port could attach to processes, read and write memory, and write arbitrary files. Version 1.1 fixes it.
| Field | Value |
|---|---|
| Product | x64dbg-mcp-server (community plugin) |
| Identifier | CVE-2026-107824 · GHSA-4478-h5jv-647m · GHSA-jgj3-97w2-9v9r |
| Severity | CVSS 4.0 9.3 (critical) |
| Affected | Versions before 1.1 |
| Fixed | 1.1 |
| Exposure | TCP 9094 (x64), 9095 (x32) on all interfaces |
How the exposure works
Analysis
This is the most common MCP vulnerability class of 2026. A server written for local, stdio-style use is moved to HTTP for convenience, without the transport’s auth model and without a loopback bind. The MCP 2026-07-28 spec tightened OAuth for remote servers (pre-registered clients and CIMD preferred, dynamic client registration deprecated, RFC 8707 resource binding), but none of that protects a server whose author skipped authentication entirely.
A debugger is about the worst tool to expose this way. Attaching to a process and writing its memory is code execution inside anything the user can debug, and reverse-engineering workstations often hold samples, credentials and unreleased research. Root cause: design flaw (insecure default bind plus no auth), not an implementation bug. Preconditions: the plugin is running and the port is reachable from another host. Blast radius: the workstation and every process its user can attach to.
Detection and mitigation
- Upgrade the plugin to 1.1.
- Find listeners. On Linux,
ss -ltnp | grep -E ':(9094|9095)'; on macOS,lsof -iTCP -sTCP:LISTEN -n -P. Broaden the search to any process listening on0.0.0.0or::that you don’t recognise; that’s how other exposed MCP servers show up. - Block at the host firewall inbound connections to MCP ports from non-local addresses as a backstop.
- Set a rule for internal MCP servers: loopback bind by default, an auth token or OAuth for anything on HTTP, and treat any HTTP MCP server without auth as a security finding.
Recommendation (opinion): act today if anyone in your organisation does reverse engineering with AI tooling. Then use this as the prompt to inventory every MCP server running on developer and analyst machines; this flaw is unlikely to be the only one of its kind.