CVE-2026-107820 in x64dbg-mcp-server
Summary
by MITRE • 10/09/2026
x64dbg-MCP Server is a native Model Context Protocol (MCP) plugin for x64dbg that exposes the debugger's full functionality over HTTP. Prior to 1.2, src/core/mcp_server.zig parses an unbounded Content-Length value in parseContentLength() and uses it in unchecked usize addition in wsRecv() before token authentication. The server listens on 0.0.0.0 by default in affected versions. An unauthenticated network client can supply a near-maximum Content-Length value to trigger a runtime integer-overflow panic in Debug and ReleaseSafe builds, terminating the entire x64dbg process and its live debugging session. The overflowed value is used only in a comparison, so the impact is limited to denial of service rather than memory corruption or code execution. This issue is fixed in version 1.2.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 10/09/2026
The vulnerability identified in versions prior to 1.2 of x64dbg-MCP Server represents a critical reliability flaw within the native Model Context Protocol implementation for the popular x64dbg debugger. As an HTTP-based interface exposing full debugging capabilities, this plugin allows external clients to interact with the debugger's internal state and functions over standard network protocols. The core issue stems from inadequate input validation during the parsing of HTTP headers, specifically regarding the Content-Length field which dictates the size of the message body expected by the server. In affected versions, the parseContentLength function fails to enforce reasonable bounds on this value, allowing an attacker or misconfigured client to supply a near-maximum integer value for content length without triggering immediate validation errors before further processing occurs.
The technical mechanism of exploitation involves unchecked arithmetic operations within the wsRecv function which handles WebSocket reception logic that is invoked prior to token authentication checks. When the unbounded Content-Length value retrieved from the HTTP header is utilized in an addition operation, it exceeds the maximum capacity for a usize data type on 64-bit systems. This results in a runtime integer overflow panic rather than silent memory corruption or wraparound behavior typical of lower-level languages like C or C++. Because x64dbg-MCP Server listens on all network interfaces by default (0.0.0.0), this vulnerability is remotely exploitable over the local area network without requiring any prior authentication credentials, significantly lowering the barrier for exploitation compared to vulnerabilities that require valid session tokens.
The operational impact of this flaw is strictly limited to denial of service due to the specific way the overflowed value is consumed within the application logic. The oversized integer derived from the Content-Length header is primarily used in a comparison operation rather than being directly applied as an allocation size or buffer index for memory writes. Consequently, while the arithmetic error triggers a fatal panic that terminates the entire x64dbg process and abruptly ends any active debugging sessions, it does not lead to arbitrary code execution, privilege escalation, or direct memory corruption vulnerabilities such as stack smashing or heap overflow. This distinction is crucial for risk assessment, as it classifies the severity primarily around availability disruption rather than confidentiality or integrity compromise of the host system's kernel or other processes.
From a standards perspective, this vulnerability aligns with CWE-190 Integer Overflow or Wraparound and CWE-287 Improper Authentication since authentication checks are bypassed by triggering the crash during initial request handling. In terms of adversarial tactics, it corresponds to ATT&CK technique T1499 Endpoint Denial of Service where an attacker disrupts service availability through resource exhaustion or application crashes rather than destructive malware deployment. The lack of input validation on network-facing HTTP headers is a common pattern in early-stage API implementations and highlights the necessity for rigorous boundary checking even when the immediate exploitability leads only to process termination.
Mitigation strategies focus heavily on upgrading to version 1.2 where this parsing logic has been corrected to validate Content-Length values against safe limits before they are used in arithmetic operations. For environments unable to upgrade immediately, network-level controls such as firewall rules restricting access to port 80 or the specific MCP server endpoint should be implemented to prevent unauthenticated external hosts from reaching the vulnerable code path. Additionally, configuring the application to bind only to localhost (127.0.0.1) rather than all interfaces reduces the attack surface by ensuring that only local processes can interact with the debugger interface, thereby eliminating remote exploitation vectors entirely until a permanent patch is applied.