Description

utcp-mcp (the MCP plugin of python-utcp) through 1.1.2 connects to the HTTP and WebSocket MCP server URLs given in a call template's mcpServers configuration without the ensure_secure_url validation that the HTTP-family plugins apply, so the HTTPS/WSS-or-loopback rule is not enforced. A call template naming a plain-HTTP, non-loopback MCP server URL is dialed as configured, exposing the MCP handshake to network interception and permitting cleartext connections to internal hosts. The mcpServers configuration is operator-authored rather than remote data, and the connection is an MCP handshake rather than an arbitrary request returning a body, which limits practical exploitation; the OAuth2 token_url credential path described in the original report was not reachable in the affected versions, because the OAuth2 handler was never invoked and the call template's auth field was not read. Fixed in utcp-mcp 1.1.3, which validates server URLs before any connection is made.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "3.1",
  "pubDate": "2026-09-27T18:16:31.823Z",
  "pubdate": "2026-09-27T18:16:31.823Z",
  "executiveSummary": "The utcp-mcp plugin for python-utcp, in versions up to 1.1.2, suffers from a lack of secure URL validation in its mcpServers configuration.\nThe vulnerability allows the establishment of cleartext HTTP and WebSocket connections to non-loopback endpoints, bypassing mandatory HTTPS/WSS security requirements.\nThis flaw exposes the Model Context Protocol (MCP) handshake to network interception, enabling potential Man-in-the-Middle (MitM) attacks.\nWhile the configuration is operator-authored and the scope of the MCP handshake limits arbitrary data exfiltration, the capability to initiate cleartext connections to internal hosts presents a significant security risk for organizations relying on secure communication protocols.\nThe vulnerability is specifically constrained because the OAuth2 credential handlers are not invoked and arbitrary request bodies cannot be returned, limiting the utility for typical credential theft, yet it remains a critical concern regarding network segment integrity and transport-layer security enforcement.",
  "technicalDetails": "The root cause of this vulnerability lies in the absence of an 'ensure_secure_url' validation check within the connection logic of the utcp-mcp plugin. Unlike other HTTP-family plugins that strictly enforce HTTPS/WSS or loopback address restrictions, utcp-mcp processes URLs defined in the 'mcpServers' configuration object without performing adequate protocol or destination validation.\nWhen a call template specifies an MCP server URL, the plugin initiates the connection directly as configured. If an operator provides a non-loopback, plain-HTTP URL, the plugin proceeds to establish an unencrypted socket connection. This bypasses the security architectural standard intended to prevent the leakage of sensitive handshake data over insecure networks.\nThe attack flow proceeds as follows: 1) An operator, potentially misled or acting under compromised configuration management, defines an insecure URL in the mcpServers configuration. 2) Upon trigger, the utcp-mcp plugin iterates through the configuration without validating the scheme or host destination against a security policy. 3) The plugin initiates the MCP handshake over an unencrypted channel. 4) An attacker positioned on the network path between the client and the target can intercept the cleartext handshake. 5) By forcing cleartext connections to internal, potentially sensitive network segments, the attacker can probe or interact with services that would otherwise be protected by mandatory transport-layer encryption.\nAlthough the affected component, utcp-mcp, does not invoke the OAuth2 handler or read the 'auth' field in these versions, the capability to force cleartext connections remains a security regression. The lack of validation allows for unauthorized cleartext transport of the MCP protocol, which is inherently vulnerable to interception and potential session manipulation depending on the specific MCP server implementation.\nThe vulnerability is fixed in version 1.1.3, which introduces a mandatory validation check to enforce secure URL schemes (HTTPS/WSS) or restricted loopback connectivity before any connection attempt is made, effectively remediating the underlying flaw."
}