CVE-2026-101057: utcp-mcp before 1.1.3 SSRF via unvalidated MCP server URL
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 ensuresecureurl 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 tokenurl 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.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
utcp-mcpto a version that resolves this vulnerability.Fixed in 1.1.3
Event History
Frequently Asked Questions
Who is realistically exposed to this issue?
Deployments using utcp-mcp through 1.1.2 are exposed only when an operator-authored call template configures an mcpServers entry with a plain-HTTP non-loopback URL. The configuration is not sourced from remote data, which limits who can introduce the risky target.
What does an attacker need to exploit this?
An attacker would need a call template to direct utcp-mcp to a plain-HTTP MCP server they can intercept, or to an internal host reachable from the deployment. The affected connection performs an MCP handshake rather than an arbitrary request that returns a response body, limiting practical SSRF impact.
Are OAuth2 token_url credentials exposed through this flaw?
No. In the affected versions, the OAuth2 handler was never invoked and the call template auth field was not read, so the reported OAuth2 token_url credential path was not reachable.
What should be done if upgrading is not immediately possible?
Review operator-authored call templates and ensure mcpServers entries use HTTPS or WSS URLs, or loopback addresses where appropriate. Remove or replace plain-HTTP non-loopback MCP server URLs.
How can I determine whether the fix is present?
utcp-mcp 1.1.3 validates MCP server URLs before making a connection. Versions through 1.1.2 do not enforce the HTTPS/WSS-or-loopback rule for these URLs.