A method for detecting remote code execution vulnerabilities for MCP client applications

Abstract

This invention discloses a remote code execution vulnerability detection method for MCP client applications. This method, for the first time, systematically summarizes and defines three common RCE vulnerability patterns in Electron-based MCP clients, targeting three attack paths: HTTP server exposure, protocol processor calls, and rendering engine injection. Based on this, corresponding vulnerability identification rules and verification processes are proposed to support security assessment of MCP clients. For MCP clients implemented with Electron architecture, a complete technical solution is established, focusing on three high-risk trigger surfaces: HTTP management interface, protocol processor, and rendering chain. This solution encompasses vulnerability pattern modeling, vulnerability feature extraction, candidate point identification, exploitability verification, and mitigation measure output. This solution transforms security vulnerabilities, originally scattered across different implementation modules, into describable, reproducible, and verifiable detection objects, overcoming the shortcomings of existing methods in unifying the analysis of the complex attack surface of MCP clients.

Description

Technical Field

[0001] This invention relates to the field of software security vulnerability detection, and in particular to a method for detecting remote code execution vulnerabilities in MCP client applications, and a method for detecting remote code execution (RCE) vulnerabilities in Model Context Protocol (MCP) client applications. Background Technology

[0002] Model Context Protocol (MCP) is a standardized specification designed to enable Large Language Models (LLMs) to interact with external data systems and tools. MCP employs a unified client-server architecture, where the server exposes its capabilities through three core primitives: Resources, Prompts, and Tools. By decoupling the model's intelligence from the underlying data source, MCP allows a single client to orchestrate multiple local and remote services, transforming previously fragmented integration methods into a unified standard. Since its release in 2024, MCP has seen widespread adoption, fostering a rapidly growing ecosystem of third-party MCP servers and clients.

[0003] The MCP client is a core component of the MCP ecosystem, typically implemented as a desktop application, responsible for coordinating communication between the LLM and the MCP server. A core responsibility of the MCP client is managing the lifecycle of the MCP server. Depending on the deployment model, the server can be started locally as a child process via stdio or connected remotely via network methods such as HTTP. For local MCP servers, the client typically utilizes operating system-level process creation mechanisms to start the server process, providing the executable path, command-line arguments, and environment variables as part of the server configuration.

[0004] While MCP significantly improves system scalability, it also introduces new security challenges. However, current security research primarily focuses on the threats posed by malicious MCP servers. Existing research has demonstrated how untrusted servers can exploit context windows for indirect prompt injection attacks, and there are risks of content poisoning and data leakage when agents interact with unverified third-party services. Despite these studies targeting MCP servers, a comprehensive analysis of how MCP clients might be insecurely exposed and the potential security impacts of such exposure is still lacking.

[0005] However, MCP clients suffer from a fundamental conflict between functional scalability and parameter sanitization in their design. MCP is designed to support a wide variety of local MCP servers, including widely used package runners (such as npx and uvx), language runtimes (such as Node and Python), and custom-compiled binaries (such as Go and Rust programs). This demands flexible and diverse parameters, making parameter sanitization extremely difficult. In fact, these parameters are not sanitized at the MCP SDK level, and similarly, they are typically not sanitized at the MCP client application level. Furthermore, MCP clients often lack explicit user authentication mechanisms, meaning that once an attacker gains access to sensitive MCP server management APIs, they can use stdio transfers to generate malicious child processes, thereby achieving arbitrary command execution.

[0006] Existing security detection methods primarily focus on security issues on the MCP server side, failing to effectively detect RCE vulnerabilities in the MCP client caused by insecure interface exposure, lack of parameter sanitization, and absence of user confirmation mechanisms. Specifically, the following problems exist:

[0007] (1) The attack surface is diverse and complex. MCP clients are usually developed based on the Electron framework and include a main process and a rendering process. The MCP server manager runs in the main process, and its functions can be provided to the outside world through various means such as HTTP API, ProtocolHandler API and inter-process communication (IPC) interface. The attack entry points are scattered and of different types, making it difficult to analyze them in a unified manner.

[0008] (2) The vulnerability pattern is fundamentally different from traditional vulnerabilities. The RCE vulnerability in the MCP client is not a traditional buffer overflow or injection vulnerability, but a new vulnerability pattern caused by multiple factors such as the Electron desktop application architecture, MCP protocol design constraints and LLM interaction, which makes the existing detection rules unable to be directly reused.

[0009] (3) The vulnerability chain spans multiple system layers. From external triggering sources (such as HTTP requests, deep links, rendering engines) to the final process spawn, the vulnerability exploitation chain often spans the network layer, application layer, rendering layer and operating system layer, requiring the establishment of a systematic vulnerability pattern system for Electron application architecture.

[0010] To address the above shortcomings, this invention proposes a remote code execution vulnerability detection method for MCP client applications. Summary of the Invention

[0011] The purpose of this invention is to address the shortcomings of existing MCP client security detection methods by proposing a remote code execution vulnerability detection method for MCP client applications. The core contribution of this method lies in: for the first time, systematically summarizing and defining three common RCE vulnerability patterns in Electron-based MCP clients, targeting three attack paths: HTTP server exposure, protocol processor calls, and rendering engine injection; based on this, corresponding vulnerability identification rules and verification processes are proposed to support security assessment of MCP clients.

[0012] The objective of this invention is achieved through the following technical solution:

[0013] This invention discloses a remote code execution vulnerability detection method for MCP client applications. Targeting the MCP server management function of the MCP client, it summarizes common RCE vulnerability patterns in Electron-based MCP clients, extracts corresponding vulnerability feature rules, guides the identification and exploitability verification of vulnerability candidates, and outputs mitigation suggestions. The method includes the following steps:

[0014] 1) MCP Client Architecture Analysis and Vulnerability Pattern Modeling: Analyze the architecture of the target MCP client, identify the vulnerability triggering paths in the main process and rendering process, and summarize the RCE vulnerability pattern system, including HTTP server exposure pattern, protocol processor call pattern and rendering injection pattern.

[0015] 2) Vulnerability feature extraction: Based on the vulnerability pattern system established in step 1), extract code features and configuration features that can be used for detection for each type of vulnerability pattern, forming a vulnerability feature rule set including vulnerability features of HTTP server exposure pattern, vulnerability features of protocol processor call pattern, and vulnerability features of rendering injection pattern.

[0016] 3) Vulnerability candidate identification: Based on the vulnerability feature rule set in step 2), the source code of the target MCP client is examined to locate candidate points that match the vulnerability pattern and output a candidate discovery list.

[0017] 4) Vulnerability exploitability verification: Perform data flow tracing and security restriction checks on the candidate discovery list identified in step 3), and verify end-to-end exploitability by constructing exploit samples in an isolated environment, and confirm the existence and exploitability of vulnerabilities by executing exploit samples.

[0018] 5) Mitigation design: For the vulnerabilities identified as existing and exploitable in step 4), targeted mitigation suggestions are provided at both the entry and execution levels of the MCP client vulnerability trigger path.

[0019] As a further improvement, the HTTP server exposure mode described in this invention refers to the HTTP management service being bound to a non-loopback network interface and lacking an authentication mechanism, which allows the stdio process generation interface to be directly called remotely; the protocol processor call mode refers to the custom URL protocol processor triggering the MCP server registration and startup process without explicit user confirmation after receiving external encoded parameters; the rendering injection mode refers to the existence of an executable JavaScript injection point in the rendering process, and the lack of access control between this process and the main process MCP management IPC interface, allowing the injected script to call privileged interfaces to complete process generation.

[0020] As a further improvement, the vulnerability features extracted for the rendering injection mode in step 2) of this invention are further subdivided into three categories of sub-features:

[0021] Mermaid chart rendering sub-features detect whether the securityLevel configuration of the Mermaid rendering component is loose, which allows the compilation artifacts to include an executable javascript: pseudo-protocol processor;

[0022] The dynamic visualization code execution sub-feature detects whether the visualization rendering module uses new Function() or eval() dynamic code execution constructors to process external input, and whether the content security policy contains the unsafe-eval directive;

[0023] The HTML direct rendering sub-feature detects whether there are code paths in the message rendering pipeline that directly assign LLM returned content to innerHTML or dangerouslySetInnerHTML without cleanup.

[0024] As a further improvement, step 3) of this invention involves inspecting the source code of the target MCP client, covering the following dimensions:

[0025] The instantiation location of StdioClientTransport and the source of its command and args parameters; the binding of the host parameter of the HTTP service listening address and the authentication status of the management route;

[0026] Protocol processor registration call and its parameter processing logic;

[0027] The rendering module contains an insecure render receiver, Mermaid security configuration, and dynamic code execution constructs.

[0028] As a further improvement, the protocol processor registration call in this invention is setAsDefaultProtocolClient, the insecure rendering receiver in the rendering module is innerHTML and dangerouslySetInnerHTML, the Mermaid security configuration is securityLevel: 'loose', and the dynamic code execution constructor is new Function and eval.

[0029] As a further improvement, the mitigation measures at the entry level in step 5) of this invention include: explicitly binding the service to the loopback interface 127.0.0.1 for the HTTP server exposure mode; using libraries such as DOMPurify to clean up the HTML content for the rendering injection mode; configuring the Mermaid security level to strict mode; implementing a CSP strategy that prohibits unsafe-eval; and replacing dynamic code execution constructs with a restricted parser.

[0030] As a further improvement, the execution-level mitigation measures in step 5) of the present invention include: triggering a mandatory user authorization dialog box before any operation of adding or starting the MCP server, and decoding and displaying the complete command and args parameters in the dialog box to ensure that the user authorizes execution with full knowledge.

[0031] The beneficial effects of this invention are:

[0032] (1) Overall, unlike existing methods that mainly focus on the risks of malicious MCP servers, general Web vulnerabilities, or rely on scattered manual experience for investigation, this invention targets MCP clients implemented using the Electron architecture. It establishes a complete technical solution around three high-risk trigger surfaces: the HTTP management interface, the protocol processor, and the rendering link. This solution encompasses vulnerability pattern modeling, vulnerability feature extraction, candidate point identification, exploitability verification, and mitigation measure output. This solution can transform security vulnerabilities that were originally scattered across different implementation modules into describable, reproducible, and verifiable detection objects, overcoming the shortcomings of existing methods in unifying the analysis of the complex attack surface of MCP clients.

[0033] (2) In step 1), MCP client architecture analysis and vulnerability pattern modeling, compared with existing methods that usually focus on a single vulnerability point or a single component, this invention focuses on the key execution link of "external trigger source - configuration parsing logic - MCP server manager - stdio startup logic - operating system process generation", and summarizes three types of RCE vulnerability patterns: HTTP server exposure pattern, protocol processor call pattern and rendering injection pattern. This improves the scattered attack phenomenon against Electron desktop applications into a reusable and scalable vulnerability pattern system.

[0034] (3) In step 2), vulnerability feature extraction, compared to detection approaches that rely on complete program semantic recovery, heavy program analysis, or pure black-box interaction, this invention further extracts directly applicable code features and configuration features for each vulnerability pattern. For example, for the HTTP server exposure pattern, network binding features, authentication missing features, and stdio transmission instantiation features are extracted; for the protocol processor call pattern, protocol registration features, parameter encoding features, and confirmation missing features are extracted; and for the rendering injection pattern, three sub-features are extracted: Mermaid chart rendering, dynamic visualization code execution, and direct HTML rendering. The above feature rule set can be implemented without relying on complete program semantic recovery, and has good coverage and portability.

[0035] (4) In the mitigation design in step 5), this invention proposes a layered approach of entry-level protection and execution-level protection. On the one hand, it compresses the attack entry point through loopback address binding, input purification, strict Mermaid configuration, CSP restrictions, and replacement of dynamic execution constructs; on the other hand, it blocks the final process generation behavior through a mandatory user authorization dialog box and a transparent command parameter display mechanism, thereby forming a remediation solution that is engineering-feasible. Attached Figure Description

[0036] Figure 1 This is the flowchart of this method. Detailed Implementation

[0037] This invention discloses a method for detecting remote code execution vulnerabilities in MCP client applications. If an MCP client has security flaws when exposing MCP server management functions, attackers can use various methods to invoke these functions to launch malicious processes and achieve remote code execution. This invention first performs a system analysis of the MCP client architecture, summarizes the commonly existing RCE vulnerability patterns, and then extracts vulnerability feature rules to guide the identification and verification of candidate vulnerabilities. It should be understood that the specific embodiments described herein are only for explaining the invention and are not intended to limit the invention.

[0038] Combination Figure 1 This invention provides a method for detecting remote code execution vulnerabilities in MCP client applications, specifically including the following steps:

[0039] 1) MCP Client Architecture Analysis and Vulnerability Pattern Modeling

[0040] An architectural analysis was conducted on the target MCP client to identify key components and vulnerability triggering paths, and to summarize the RCE vulnerability pattern system. MCP clients are typically implemented based on the Electron framework and contain two types of execution contexts: a main process and a rendering process. The main process is responsible for window management, protocol handler registration, HTTP service listening, and adding, connecting to, and starting the MCP server; the rendering process is responsible for message display, chart rendering, and user interaction; and the preloaded scripts are responsible for exposing some of the main process's capabilities to the rendering process through a context bridging mechanism.

[0041] Subsequently, the startup path of the MCP server was located, with a focus on identifying the creation logic of the local MCP server under stdio transmission mode. In this logic, the MCP client creates a local child process based on the command, args, and env parameters in the MCP server configuration. Because the MCP protocol needs to be compatible with various local server formats such as npx, uvx, node, python, and custom binaries, the command and args parameters are difficult to effectively whitelist. Therefore, if external input can reach this startup path, it poses a risk of command execution.

[0042] After identifying the startup path, the externally accessible trigger channels are analyzed, mainly including: first, the MCP server add, connect, update, or start functions exposed by the main process via HTTP interface; second, custom URL protocol handlers registered through interfaces such as setAsDefaultProtocolClient; and third, the path where the rendering process calls the MCP server management functions in the main process via IPC interface. Based on the above analysis, the key exploit chain of the program under test can be uniformly abstracted as "external trigger source—configuration parsing logic—MCP server manager—stdio startup logic—operating system process generation".

[0043] Based on this exploit chain, this invention categorizes the RCE risks in MCP clients into three vulnerability patterns: (a) HTTP server exposure pattern: The HTTP management service is bound to a non-loopback network interface, and the management interface for adding or starting the MCP server lacks an authentication mechanism, allowing attackers to directly submit malicious MCP server configurations and trigger stdio child process generation via network requests. (b) Protocol processor call pattern: After receiving externally encoded parameters, the custom URL protocol processor parses and executes MCP server registration, connection, or startup operations without explicit user confirmation, allowing attackers to trigger command execution via deep links. (c) Rendering injection pattern: There is an injection point in the rendering process that can execute JavaScript, and the main process exposes IPC capabilities related to MCP server management to the rendering process. The injected script can use this capability to call privileged interfaces and complete process generation.

[0044] 2) Vulnerability Feature Extraction

[0045] Based on the vulnerability pattern system established in step 1), code features and configuration features that can be used for detection are extracted for each type of vulnerability pattern to form a vulnerability feature rule set.

[0046] The vulnerability characteristics of the HTTP server exposure pattern are as follows: (a) Network binding characteristics: Detect whether the HTTP service listening address is set to 0.0.0.0, ::, or the host parameter is not explicitly specified. For the Node.js runtime, not explicitly specifying the host parameter usually means listening to all network interfaces, so it should be considered a high-risk characteristic; (b) Authentication missing characteristics: Detect whether the routes related to MCP server management lack authentication middleware, token verification, session verification, or source restriction, such as directly reading the request body and entering the business logic when receiving requests for adding, connecting, or updating servers; (c) stdio transport instantiation characteristics: Detect whether there is an instantiation of StdioClientTransport on the request processing path, or whether there is logic that determines the configuration type based on the command and args fields and then calls child_process.spawn.

[0047] Vulnerability characteristics of protocol processor call patterns: (a) Protocol registration characteristics: Detect whether the application registers a custom URL protocol through system calls such as setAsDefaultProtocolClient; (b) Parameter encoding characteristics: Detect whether the protocol processor reads parameters such as config and json from deep links and restores the MCP server configuration object using Base64 or other encoding methods; (c) Missing confirmation characteristics: Detect whether the protocol processor directly triggers the registration, connection, or startup of the MCP server without popping up an explicit user confirmation dialog box after parsing the configuration parameters.

[0048] Vulnerability characteristics of the rendering injection pattern: further subdivided into three sub-characteristics: (a) Mermaid chart rendering sub-characteristics: detect whether the securityLevel configuration of the Mermaid rendering component is loose; detect whether it supports interactive instructions such as click and callback; detect whether the compilation artifact may contain a javascript: pseudo-protocol processor; and detect whether the rendering layer can access the MCP server management interface through bridge objects such as fetch, ipc.invoke, or window.electron. (b) Dynamic visualization code execution sub-characteristics: detect whether the visualization rendering module uses new Function() or eval() to process external input or configuration data returned by LLM; detect whether there is an unsafe-eval directive in the Content Security Policy (CSP), thereby allowing dynamic execution constructs to take effect at runtime. (c) HTML direct rendering sub-characteristics: detect whether there is an implementation path in the message rendering pipeline that directly assigns the content returned by LLM to innerHTML or dangerouslySetInnerHTML without using cleansing components such as DOMPurify, and whether JavaScript execution can be triggered by the onerror event of the img tag or an equivalent HTML event.

[0049] 3) Vulnerability candidate identification

[0050] Based on the vulnerability feature rule set in step 2), the source code of the target MCP client is examined to locate candidate points matching the vulnerability pattern and output a candidate discovery list. During implementation, keyword retrieval, pattern matching, or AST static analysis can be used to process the source code in batches. The inspection process covers the following dimensions: (a) locating the stdio transport instantiation point, searching for the instantiation location of StdioClientTransport, and extracting the source of the command and args parameters; (b) detecting the host parameter binding and management route authentication in the HTTP service configuration; (c) retrieving protocol processor registration calls and their parameter processing logic; (d) scanning for insecure render receivers (such as innerHTML), Mermaid security configurations, and dynamic code execution constructs (such as new Function) in the rendering module. After the inspection is completed, a candidate discovery list containing precise locations and code context is output.

[0051] 4) Vulnerability exploitability verification

[0052] Each item in the candidate discovery list undergoes availability verification, specifically including:

[0053] (a) Data Flow Tracing: For each candidate point, starting from the external input, trace the propagation path of key parameters between adjacent modules layer by layer. For the HTTP server exposure mode, focus on tracing whether the configuration items related to the MCP server in the HTTP request body reach StdioClientTransport or child_process.spawn via management routing, configuration judgment logic, and connection logic; for the protocol processor call mode, focus on tracing whether the config parameters in the deep link reach the startup logic via Base64 decoding, configuration restoration, and installation processes; for the rendering injection mode, focus on tracing whether the script executed in the rendering layer can call the MCP server management interface in the main process via fetch or IPC bridge object and finally reach the stdio startup endpoint. If the data flow from the external input to the process generation point is continuously reachable, it indicates that the candidate point has the basis for forming an exploit chain.

[0054] (b) Security Restriction Check: After completing data flow tracing, check whether there are effective security restrictions on the path. For HTTP server exposure mode, check whether the service is only bound to the loopback interface and whether the management route requires token, session, or origin verification; for protocol processor call mode, check whether there are unbypassable secondary confirmation boxes and whether the confirmation boxes display the complete command and args parameters; for render injection mode, check whether DOMPurify is used for purification, whether Mermaid is configured in strict mode, whether unsafe-eval is disabled in CSP, whether the dynamic visualization module still uses new Function or eval, and whether the rendering layer's access to the MCP management IPC interface is restricted. If any of the authentication, purification, or confirmation steps in the path is missing, or if there are bypassable implementation defects such as "front-end interception but back-end continued execution," then the candidate point is further judged as a high-risk candidate point.

[0055] (c) Exploitation of Samples: For candidate points identified as vulnerabilities, construct an MCP server configuration containing specific executable commands as an exploit sample, trigger the corresponding vulnerability path in an isolated local test environment, and observe whether the target command is executed to verify end-to-end exploitability.

[0056] In the actual verification of this invention, the test objects were preferably selected from the community-maintained list of MCP clients on GitHub, and further filtered out closed-source projects, SDK projects, and non-client projects, ultimately forming a dataset of 67 popular MCP clients. Using the above steps, this dataset was evaluated, identifying 135 vulnerability candidates, and ultimately confirming 17 previously unknown RCE vulnerabilities involving 12 different MCP clients. Among these, 15 vulnerabilities obtained CVE (Common Vulnerabilities & Exposures) numbers, and most of the confirmed vulnerabilities reached a severe risk level. Furthermore, among the confirmed vulnerabilities, 5 belong to the HTTP server exposure pattern, 1 to the protocol processor call pattern, and 11 to the rendering injection pattern. These results demonstrate that the vulnerability pattern modeling, feature extraction, and verification process proposed in this invention can effectively cover the main high-risk exploitation paths of MCP clients in the real world and has good detection performance.

[0057] 5) Design of mitigation measures

[0058] Mitigation strategies are proposed from two levels: the entry point and the implementation level.

[0059] Entry-level mitigation measures: For HTTP server exposure mode, the HTTP service should be explicitly bound to the loopback interface 127.0.0.1, and authentication or source restrictions should be added to the MCP server management interface; for Mermaid chart rendering and direct HTML rendering scenarios, purification components such as DOMPurify should be used to clean the HTML and chart content, and the Mermaid security level should be configured to strict mode to block execution risks caused by javascript: pseudo-protocol processors, click callbacks, and HTML injection; for dynamic visualization code execution scenarios, a CSP strategy that prohibits unsafe-eval should be implemented, and dynamic code execution constructs such as new Function and eval should be replaced with a JSON parser or a restricted parser.

[0060] Execution-level mitigation measures: A mandatory user authorization dialog box should be triggered before any operation adding, connecting to, or starting an MCP server, interrupting the automated execution flow. The authorization interface must decode and display the complete command and args parameters, allowing users to decide whether to authorize execution with full knowledge. This mechanism is particularly critical for protocol processor call patterns, as parameters are often obfuscated using Base64 or other encoding methods in such scenarios. Simply prompting "Open application?" without displaying the actual execution content will not prevent deep link attacks.

[0061] In practical applications of this invention, maintainers have adopted the aforementioned mitigation approach to fix multiple projects, including changing the HTTP service to only listen on 127.0.0.1, adjusting the Mermaid security configuration to strict, removing unsafe-eval, replacing new Function with secure parsing methods such as JSON5.parse, and adding a confirmation dialog box before installing the MCP server via deep linking. This further demonstrates that this invention can not only discover vulnerabilities but also directly guide project repair, possessing clear practical value.

[0062] The foregoing description of the embodiments is intended to enable those skilled in the art to understand and apply the present invention. It will be apparent to those skilled in the art that various modifications can be made to the foregoing embodiments, and the general principles of the invention can be applied to other embodiments without creative work. Therefore, the present invention is not limited to the foregoing embodiments. Based on the disclosure of the present invention, those skilled in the art can make improvements and modifications, and all such improvements and modifications should be included within the scope of protection of the present invention.

Claims

1. A method for detecting remote code execution vulnerabilities in MCP client applications, characterized in that, Targeting the MCP server management function of the MCP client, this study summarizes common RCE vulnerability patterns in Electron-based MCP clients, extracts corresponding vulnerability characteristic rules, guides the identification and exploitability verification of vulnerability candidates, and outputs mitigation suggestions, including the following steps: 1) MCP Client Architecture Analysis and Vulnerability Pattern Modeling: Analyze the architecture of the target MCP client, identify the vulnerability triggering paths in the main process and rendering process, and summarize the RCE vulnerability pattern system, including HTTP server exposure pattern, protocol processor call pattern and rendering injection pattern. 2) Vulnerability feature extraction: Based on the vulnerability pattern system established in step 1), extract code features and configuration features that can be used for detection for each type of vulnerability pattern, forming a vulnerability feature rule set including vulnerability features of HTTP server exposure pattern, vulnerability features of protocol processor call pattern, and vulnerability features of rendering injection pattern. 3) Vulnerability candidate identification: Based on the vulnerability feature rule set in step 2), the source code of the target MCP client is examined to locate candidate points that match the vulnerability pattern and output a candidate discovery list. 4) Vulnerability exploitability verification: Perform data flow tracing and security restriction checks on the candidate discovery list identified in step 3), and verify end-to-end exploitability by constructing exploit samples in an isolated environment, and confirm the existence and exploitability of vulnerabilities by executing exploit samples. 5) Mitigation design: For the vulnerabilities identified as existing and exploitable in step 4), targeted mitigation suggestions are provided at both the entry and execution levels of the MCP client vulnerability trigger path.

2. The method of claim 1, wherein the method further comprises: The HTTP server exposure mode refers to the HTTP management service being bound to a non-loopback network interface and lacking an authentication mechanism, which allows the stdio process generation interface to be directly called remotely; the protocol processor call mode refers to the custom URL protocol processor triggering the MCP server registration and startup process without explicit user confirmation after receiving external encoded parameters; the rendering injection mode refers to the existence of an executable JavaScript injection point in the rendering process, and the lack of access control between this process and the main process MCP management IPC interface, allowing the injected script to call privileged interfaces to complete process generation.

3. The remote code execution vulnerability detection method for MCP client applications according to claim 1, characterized in that, The vulnerability features extracted from the rendering injection mode as described in step 2) are further subdivided into three categories of sub-features: Mermaid chart rendering sub-features detect whether the securityLevel configuration of the Mermaid rendering component is loose, which allows the compilation artifacts to include an executable javascript: pseudo-protocol processor; The dynamic visualization code execution sub-feature detects whether the visualization rendering module uses new Function() or eval() dynamic code execution constructors to process external input, and whether the content security policy contains the unsafe-eval directive; The HTML direct rendering sub-feature detects whether there are code paths in the message rendering pipeline that directly assign LLM returned content to innerHTML or dangerouslySetInnerHTML without cleanup.

4. The remote code execution vulnerability detection method for MCP client applications according to claim 1, characterized in that, Step 3) describes inspecting the source code of the target MCP client, covering the following dimensions: The instantiation location of StdioClientTransport and the source of its command and args parameters; the binding of the host parameter of the HTTP service listening address and the authentication status of the management route; Protocol processor registration call and its parameter processing logic; The rendering module contains an insecure render receiver, Mermaid security configuration, and dynamic code execution constructs.

5. The remote code execution vulnerability detection method for MCP client applications according to claim 4, characterized in that, The protocol processor registration call is setAsDefaultProtocolClient, the insecure rendering receiver in the rendering module is innerHTML and dangerouslySetInnerHTML, the Mermaid security configuration is securityLevel: 'loose', and the dynamic code execution constructor is new Function and eval.

6. The remote code execution vulnerability detection method for MCP client applications according to claim 1, characterized in that, The entry-level mitigation measures described in step 5) include: explicitly binding the service to the loopback interface 127.0.0.1 for the HTTP server exposure mode; using libraries such as DOMPurify to clean up HTML content for the render injection mode; configuring the Mermaid security level to strict mode; implementing a CSP policy that prohibits unsafe-eval; and replacing dynamic code execution constructs with a restricted parser.

7. The remote code execution vulnerability detection method for MCP client applications according to claim 1 or 6, characterized in that, The execution-level mitigation measures described in step 5) include: triggering a mandatory user authorization dialog box before any operation of adding or starting the MCP server, and decoding and displaying the complete command and args parameters in the dialog box to ensure that the user authorizes execution with full knowledge.

Images