al-ice.ai

No Auth on the Debugger’s Front Door: x64dbg-MCP Server’s CVE-2026-107824 (9.3) and CVE-2026-107820

AI Vulnerabilities & CVEs by al-ice.ai Editorial

Handing an AI assistant control of your debugger is already an aggressive trust decision. Shipping the bridge that does it with no authentication, bound to every interface, turns that decision into everyone else’s. Two CVE records published 9 October 2026 cover x64dbg-MCP Server (2,424 stars), a native MCP plugin that exposes x64dbg’s full functionality over HTTP so any MCP-compatible assistant can drive it: CVE-2026-107824, 9.3 critical (CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H, CWE-306) — every debugger tool reachable by any unauthenticated network client — and CVE-2026-107820, 5.3 medium (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L, CWE-190) — a pre-authentication integer overflow that kills the debugger process. Fixed in 1.1 and 1.2 respectively.

We verified both flaws at the source level, reading src/core/mcp_server.zig at tags 1.0 and v1.1 first-hand. The authentication in v1.1 is genuinely new code — and its absence in 1.0 is total.

Every debugger primitive, no credentials, every interface

The CVE record for CVE-2026-107824 is unusually concrete about impact. Prior to 1.1, the server exposed all MCP debugger tools over HTTP and SSE without authentication while listening on 0.0.0.0 by default. Any unauthenticated network client reaching the default port — 9094 for x64, 9095 for x32 — could execute arbitrary x64dbg commands, attach to processes by PID, read and write debuggee memory, and write files to arbitrary paths. That last pair is the whole game: memory write plus arbitrary file write on the analyst’s own machine is remote code execution wearing a lab coat.

Our source read confirms the shape of the exposure. In the 1.0 file, the port default is 9094, the bind default resolves "0.0.0.0" to INADDR_ANY, and there is no token store, no Authorization parsing, no 401 path anywhere in the file. In the v1.1 file, all of that appears at once: an auth_token store, a setConfig(ip, port, token) entry point, Bearer comparison against the stored token, and a 401 Unauthorized rejection path. Authentication was not tightened in v1.1. It was invented there.

Two observations for operators. First, the bind default is still 0.0.0.0 in v1.1 — the fix adds a gate, it does not narrow the listening surface, so a missing or empty token configuration leaves a network-reachable endpoint whose only protection is a check you may not have set up. Bind to loopback unless you have a reason not to. Second, both files set Access-Control-Allow-Origin: *. We did not test cross-origin reachability, but a wildcard CORS policy on a security-sensitive local service is the kind of thing that deserves its own audit once unauthenticated access is in the threat model.

The second CVE: one header value kills the session

CVE-2026-107820 is the smaller sibling and the more instructive code bug. Prior to 1.2, parseContentLength() in the same file accepted an unbounded Content-Length value and used it in unchecked usize addition inside wsRecv() — before token authentication. An unauthenticated client supplying a near-maximum value triggers a runtime integer-overflow panic in Debug and ReleaseSafe builds, terminating the entire x64dbg process and its live debugging session. The CVE record is careful about the blast radius: the overflowed value feeds only a comparison, so the impact is denial of service, not memory corruption or code execution.

The fix commit (0dd4204d) is the v1.2 tag itself — we confirmed the tag points at that commit — so “upgrade to 1.2” and “apply the fix” are the same statement. Note the ordering dependency the record implies: the overflow sits before token authentication, so the v1.1 auth gate does not mitigate it. Only 1.2 closes both holes, and the current release at the time of writing is v1.5 (30 September 2026).

A six-week-old fix with a brand-new identifier

The timeline here compresses the whole disclosure story into the project’s first week of life. The repository was created 22 August 2026; v1.1 (auth) and v1.2 (overflow fix) both shipped on 27 August; the CVE records were reserved on 8 October and published on 9 October (17:42Z and 17:45Z). For six weeks, a network-reachable unauthenticated debugger existed in a public, starred, MCP-ecosystem project with no identifier any scanner could key on — the same fix-then-identifier gap we documented this week in Astron Agent (32 days) and Strawberry GraphQL (39 days). Three different projects, three different ecosystems, the same structural lag: the fix ships, the identifier waits, and automated tooling sees nothing in between.

There is a second pattern worth naming, specific to the MCP gold rush. This server exists to let AI assistants operate a debugger — arguably the most privilege-dense tool on a reverse engineer’s machine — and its first public release exposed that capability to the network with no credentials. The October MCP SDK advisories and the TypeScript SDK issuer-confusion flaw keep pointing at the same lesson from different angles: MCP servers routinely bind powerful primitives to network listeners with protocol-first, authentication-later design. Debug tooling is where that habit converts most directly into host compromise, because “attach to PID, write memory, write file” is already a complete exploitation chain with no further vulnerability required.

What to do

  • Upgrade to 1.2 or later (v1.5 current at the time of writing). Version 1.1 alone closes the unauthenticated access but not the pre-auth overflow — 1.2 is the floor that covers both CVEs.
  • Configure the bearer token and bind to loopback. The v1.1+ gate only protects deployments that actually set a token, and the default bind is still all interfaces. Never expose 9094/9095 beyond localhost without a deliberate, authenticated reason.
  • Treat pre-1.1 network exposure as compromise. Arbitrary memory write plus arbitrary file write is not a “patch and move on” finding on a machine that also holds malware samples, credentials and analysis notes. If the port was reachable, rebuild confidence in the host, don’t just upgrade the plugin.
  • Audit the CORS wildcard in your deployment context. Access-Control-Allow-Origin: * on a service that executes debugger commands deserves explicit justification or removal.

Verification note: we confirmed CVE-2026-107824 and CVE-2026-107820 against the CVE records (cveawg, both state PUBLISHED, reserved 8 October 2026, published 9 October 2026 17:45:17Z and 17:42:45Z) including CVSS vectors, CWE assignments, affected ranges (< 1.1, < 1.2), ports, file and function names, and fix commits, and confirmed CVE-2026-107824 against NVD (Received, published 9 October 2026 18:17:04Z, GitHub-supplied 9.3 only). We read src/core/mcp_server.zig at tags 1.0 and v1.1 first-hand: the 9094 default, the 0.0.0.0-to-INADDR_ANY default, and the complete absence of auth machinery in 1.0, versus the auth_token store, setConfig(ip, port, token), Bearer comparison and 401 path in v1.1, are quoted from the files as observed; the wildcard CORS constant appears in both. We confirmed via the tags API that the v1.2 tag points at the overflow-fix commit 0dd4204d, and release dates (v1.1/v1.2 both 27 August 2026, v1.5 30 September 2026), star count and project creation date from repository records. Neither CVE record credits a reporter, and we name none. We found no evidence of exploitation and do not imply any, and we sent no traffic to any deployment.

Sources: