x64dbg-MCP Server before 1.1 exposed every debugger tool over HTTP, unauthenticated, on all interfaces. CVE-2026-107824 scores 9.3; no exploitation.
The x64dbg-MCP Server, a plugin that lets AI assistants drive the x64dbg debugger, exposed its full toolset over HTTP and SSE with no authentication and listened on all interfaces by default. GitHub scored the flaw, CVE-2026-107824, 9.3 (Critical) under CVSS 4.0. NVD published the record on 9 October 2026. The people at risk are reverse engineers and malware analysts who run the plugin on a workstation reachable from a shared or hostile network.
What happened
According to the GitHub advisory (GHSA-4478-h5jv-647m), any host that can open a TCP connection to the plugin's port gets unauthenticated access to every registered MCP tool, 71 in the advisory. The default ports are 9094 for the 64-bit debugger and 9095 for the 32-bit one. The advisory credits reporter avishaigonen-pluto. The weakness is CWE-306, missing authentication for a critical function. The CVSS 4.0 vector is CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N. GitHub is the scoring source, and the NVD record carries no separate NVD score.
Timeline
- 23 August: fix commits land in the repository.
- 24 August: GitHub publishes GHSA-4478-h5jv-647m.
- 27 August: releases 1.0, v1.1 and v1.2 are published; v1.2 changes the default bind to localhost.
- 9 October: the CVE record reaches NVD, about six and a half weeks after the advisory.
Anyone who relies on NVD or a CVE feed alone learned of this weeks after a fix existed.
The business and victim lens
The target is the analyst's machine. An x64dbg session is typically attached to a sample the analyst is studying. Whoever reaches the port can operate that session as the analyst would. Several consequences follow from the advisory's tool list.
- Control of the analysis. An attacker can attach to processes by PID and run arbitrary x64dbg commands. In principle that lets a remote party steer an investigation or tamper with its results.
- Code execution risk on the host. The advisory lists reading and modifying process memory, allocating memory in the debuggee, and writing files to disk through dump commands. The README names
WriteMemToAddress,ExecuteDebuggerCommand,DumpMemoryandDumpModule. Both the advisory and NVD describe this as arbitrary-path file writes to disk, through the memory and module dump commands. - Exposure of sensitive material. Memory contents and loaded modules of whatever is being debugged are readable through the same tools.
The repository shows about 2.4k stars and 263 forks. Stars say little about real deployment: we have no figure for how many instances are installed, or how many are reachable from outside.
For a security team, the lesson is that an MCP server wrapped around a debugger is a remote-control surface for whatever the debugger can touch. It deserves the same access control as an SSH daemon on that machine.
The technical lens
How an unauthenticated client reaches the debugger in versions before the fix.
The plugin runs inside x64dbg and starts automatically with it. It is written in Zig and speaks HTTP and SSE so that MCP clients can connect. Before the fix, nothing checked who was connecting, and the bind address was 0.0.0.0. Both conditions together make the attack a single network connection with no credentials, no user interaction and low complexity. We covered the same pattern in the unauthenticated TensorFold API.
Which version fixes it: 1.1, despite the advisory's label
- The GitHub advisory says versions below 1.0 are affected and lists 1.0 as patched. NVD says versions below 1.1 are affected and names 1.1 as the fix.
- The code settles it. The source at tag 1.0 contains no Bearer-token or 401 handling. Version 1.1 adds the token check in
src/core/mcp_server.zig(around lines 458 to 466) and returns 401 to requests without one. So NVD's "fixed in 1.1" is right and the advisory's range is mislabelled. - The v1.1 release notes describe new tools and behaviour and do not mention authentication, which is likely why the label drifted. The releases page dates v1.0, v1.1 and v1.2 all to 27 August.
Either way, the practical answer is to run the latest release. At the time of reading that is v1.5, from 30 September, and the README states that Bearer-token authentication is mandatory.
The default bind address changed later
The bind-address change is not in 1.1. Release v1.2 changed the default to 127.0.0.1. Existing configurations that specify 0.0.0.0 keep it, so an upgrade does not close the network exposure on its own. The README still lists 0.0.0.0 as the default host in its configuration text, so check the setting yourself.
A separate bug
v1.2 also fixed a different flaw, CVE-2026-107820 (GHSA-jgj3-97w2-9v9r): an integer overflow in Content-Length parsing that lets an unauthenticated client crash x64dbg with one request. It is rated 5.3 (Medium) under CVSS 3.1 and affects versions up to 1.1. NVD notes the panic occurs in Debug and ReleaseSafe builds, and the README's build command uses ReleaseSafe. It is a denial of service only and is separate from CVE-2026-107824.
What defenders should do
- Upgrade the plugin to the latest release (v1.5 at the time of writing), at minimum v1.2 so that both CVEs are covered.
- Open the plugin configuration and set the host to 127.0.0.1. Do not rely on the new default if the machine was configured earlier.
- Block inbound TCP 9094 and 9095 at the host firewall and on the lab network segment.
- Confirm the Bearer token is enabled, and rotate it from the configuration dialog if the plugin was ever reachable from another host.
- If an older version was exposed on a network others could reach, treat the analysis machine as potentially tampered with. Review dumped files and recent debugger activity.
- If a remote client needs access, tunnel it (for example SSH or a VPN) instead of exposing the port. The README warns that the server speaks unencrypted HTTP, so even with authentication the Bearer token crosses the network in cleartext.
Exploitation status
None of the sources we read reports exploitation in the wild or a public proof of concept. The CVE is not in CISA's Known Exploited Vulnerabilities catalogue (catalogue version 2026.10.08, checked 11 October), and a GitHub search found no public proof-of-concept repository.