GHSA-XHCR-CQFR-M3HV: Remote Code Execution via Insecure HTTP MCP Server Registry in atomic-agents-stack

The Model Context Protocol (MCP) is designed to allow Large Language Models (LLMs) and agentic applications to interface securely with external data sources and execution environments. To facilitate server discovery, applications often implement a catalog or registry system that specifies how to locate and configure external MCP servers. The package atomic-agents-stack implements this capability via the atomic_agents/mcp_registry/http.py module, which resolves remote server configurations dynamically.

The vulnerability resides in the HTTP MCP registry backend factory, which retrieves the server configurations from remote JSON endpoints. By design, these server configurations contain execution metadata, including the command and command-line arguments needed to spawn local stdio subprocesses. Because the registry factory lacks protocol restriction, it permits the retrieval of these configurations over cleartext HTTP.

This configuration model presents an unauthenticated network attack surface. Any network actor positioned to perform a Man-in-the-Middle (MITM) attack can manipulate the remote HTTP responses. Since the client implicitly trusts the returned commands, this allows a remote attacker to gain local command execution on the client host.

The root cause of GHSA-XHCR-CQFR-M3HV lies in a dual failure of communication security and payload validation. Specifically, the function make_http_mcp_server_registry_backend_from_url accepts HTTP registry URLs without enforcing transport-layer encryption. This cleartext fallback exposes the connection to modification by third parties on the network path, violating basic principles of secure data transmission (CWE-319).

Furthermore, the registry payload processing logic relies on implicit trust in the remote catalog content (CWE-494). While the system parses the JSON data and verifies structure (confirming that commands are strings and arguments are arrays), it fails to inspect the content of the commands. There is no mechanism to limit commands to a predefined allowlist of executable binaries, nor is there user verification prior to execution.

Finally, the execution layer inside MCPClientPool spawns subprocesses directly using these untrusted inputs. Because the default configuration lacks a policy-based validation callback (mcp_allow_fn defaults to None), all parsed configurations are executed automatically. This execution model guarantees that any modification to the returned JSON translates directly to local system execution.

A review of the vulnerable module atomic_agents/mcp_registry/http.py shows that the registry lookup accepts any valid URL scheme starting with http or https. When a cleartext connection is established, the HTTP client fetches the JSON payload without any integrity or authenticity verification.

The following code illustrates the vulnerable implementation pattern:

# Vulnerable: atomic_agents/mcp_registry/http.py
 
def make_http_mcp_server_registry_backend_from_url(url: str):
    # Vulnerability: Accepts insecure http:// scheme without validation
    if not (url.startswith("http://") or url.startswith("https://")):
        raise ValueError("Invalid registry URL")
    
    import httpx
    # Fetching catalog over unencrypted channel
    response = httpx.get(url, verify=True)
    return response.json()

In the patched version (1.1.0), the package restricts unencrypted HTTP URLs by default. If a developer attempts to resolve an unencrypted HTTP registry, the factory throws an exception unless an explicit override flag is supplied.

The updated, secure configuration pattern is structured as follows:

# Patched: atomic_agents/mcp_registry/http.py
 
def make_http_mcp_server_registry_backend_from_url(url: str, allow_insecure_http: bool = False):
    # Remediation: Enforce HTTPS protocol
    if url.startswith("http://") and not allow_insecure_http:
        raise ValueError(
            "Security restriction: Insecure HTTP is disallowed by default. "
            "Configure an HTTPS registry URL or explicitly set allow_insecure_http=True "
            "only in local sandbox environments."
        )
    
    if not (url.startswith("http://") or url.startswith("https://")):
        raise ValueError("Invalid registry URL")
        
    import httpx
    # Retrieve catalog safely with redirects disabled to block SSRF vectors
    response = httpx.get(url, verify=True, follow_redirects=False)
    return response.json()

Exploitation of this vulnerability requires a network-positioned attacker who can intercept transit traffic between the agent host and the HTTP registry server. This is typical in shared network environments, public Wi-Fi networks, or environments with compromised local routing infrastructure.

The attack sequence begins when the agent application requests a registry update over an insecure channel. The attacker intercepts the request and allows it to proceed to the registry, or immediately responds with a crafted JSON document. The injected JSON modifies the command and args parameters of an existing tool configuration.

Once the host application receives the response, it validates the schema and passes the parameters to the execution engine. Because there is no check on the absolute path or binary name of the command, the host spawns the attacker-specified subprocess. This executes arbitrary commands under the security context of the parent application process.

The security impact of GHSA-XHCR-CQFR-M3HV is rated High, with a CVSS v4.0 score of 8.7. The primary impact is unauthenticated remote code execution on the agent host. Because the execution is triggered during catalog resolution, no user interaction with an LLM or chat interface is required to initiate the compromise.

The injected commands execute with the same operating system permissions as the host process running atomic-agents-stack. In containerized or server environments, this can lead to container escape, access to sensitive local environment variables, or total compromise of the hosting node.

Additionally, because the vulnerability allows the attacker to execute outbound connections or pull payloads, it serves as an initial access vector for broader network penetration. Since there is currently no active exploitation recorded, organizations have an opportunity to remediate the vulnerability before threat actors construct automated exploit paths.

The definitive remediation for this vulnerability is to upgrade the atomic-agents-stack package to version 1.1.0 or greater. The patched release implements secure defaults by rejecting http:// configurations unless specifically instructed otherwise. Developers should audit dependency manifests to verify that the upgraded package is deployed across all environments.

If upgrading is not immediately possible, organizations must configure a custom policy-based verification callback (mcp_allow_fn). This callback must be designed to validate the resolved registry payload prior to execution, rejecting any entry that invokes dangerous binaries or contains unexpected parameters.

Additionally, any deployment utilizing the package must ensure that the registry URLs are strictly configured to use HTTPS. Local sandboxes that require unencrypted HTTP should only be configured with loopback addresses to restrict the attack surface to the local interface.