CVE-2026-12210

A vulnerability was detected in universal-tool-calling-protocol python-utcp 1.1.0. This affects an unknown function of the component utcp-gql/utcp-websocket. Performing a manipulation results in server-side request forgery. The attack can be initiated remotely. The exploit is now public and may be used. The vendor was contacted early about this disclosure but did not respond in any way.

A vulnerability was detected in universal-tool-calling-protocol python-utcp 1.1.0. This affects an unknown function of the component utcp-gql/utcp-websocket. Performing a manipulation results in server-side request forgery. The attack can be initiated remotely. The exploit is now public and may be used. The vendor was contacted early about this disclosure but did not respond in any way.

Summary

The fix for CVE-2026-44661 (commit 5b16e43) added the ensure_secure_url() / is_secure_url() helpers and wired them into the three HTTP-family plugins, but it did not reach the GraphQL or WebSocket plugins. The GraphQL plugin (utcp-gql) still uses the startswith prefix check that the fix explicitly replaced, so http://127.0.0.1.attacker.example and http://localhost.evil.com pass it. The WebSocket plugin (utcp-websocket) performs no URL validation at all, even though its own docstrings state it enforces "WSS or localhost only." Both plugins reach the same SSRF that CVE-2026-44661 was filed for, and because both attach the call template's configured auth headers to the outbound connection, the SSRF can also leak API keys and OAuth tokens to an attacker-controlled host.

Details

In the CVE-2026-44661 fix (commit 5b16e43 ("fix(http): block SSRF via attacker-controlled OpenAPI servers[0].url")), two things in it pointed at sibling issues. The commit message says the change is "replacing the duplicated prefix check", and the new utcp_http/_security.py docstring names the exact bug:

URLs whose hostname starts with localhost / 127.0.0.1 but isn't actually loopback (e.g. http://localhost.evil.com, http://127.0.0.1.attacker.example). The earlier startswith check let these through.

The word "duplicated" says the vulnerable check existed in more than one place. The fix only updated the three HTTP-family plugins (http, streamable_http, sse). The other communication-protocol plugins were also inspected.

GraphQL plugin (utcp-gql). plugins/communication_protocols/gql/src/utcp_gql/gql_communication_protocol.py still has the pre-fix check at line 43:

def _enforce_https_or_localhost(self, url: str) -> None:
    if not (
        url.startswith("https://")
        or url.startswith("http://localhost")
        or url.startswith("http://127.0.0.1")
    ):
        raise ValueError("Security error: URL must use HTTPS or start with ...")

It is called on manual_call_template.url in register_manual (line 102) and on tool_call_template.url in call_tool (line 181). The URL then goes into AIOHTTPTransport(url=...) and a live GraphQL request.

"http://127.0.0.1.attacker.example/graphql".startswith("http://127.0.0.1") is True, so the check passes. If the attacker controls DNS for attacker.example, that hostname resolves to any address they choose, including 169.254.169.254, 127.0.0.1, or an internal 192.168.x.x host, and the GraphQL client sends a plain-HTTP request there. http://localhost.evil.com/graphql behaves the same way. This is the exact prefix bypass CVE-2026-44661 was filed for.

WebSocket plugin (utcp-websocket). plugins/communication_protocols/websocket/src/utcp_websocket/websocket_communication_protocol.py. The module and class docstrings state:

"Security enforcement (WSS or localhost only)" "Enforces security by requiring WSS or localhost connections" "Security validation of connection URLs"

There is no such validation in the code. _get_connection(), the only connection path (used by register_manual, call_tool, and call_tool_streaming), calls:

ws = await session.ws_connect(call_template.url, headers=headers, ...)   # line 197

with no scheme or host check. Any URL in a WebSocketCallTemplate connects, including ws://169.254.169.254/, ws://127.0.0.1:<internal-port>/, or any internal hostname.

Credential exposure. Both plugins build connection headers in _prepare_headers(), which attaches the configured auth: ApiKeyAuth as a header, BasicAuth as an Authorization: Basic header, and OAuth2Auth as an Authorization: Bearer token. When the bypass is used to force a plain-HTTP or plain-WS connection to an attacker-resolved host, those credentials are sent to the attacker.

This is the threat model CVE-2026-44661 already established: a UTCP client ingests tool manuals, and a malicious…

Duplicate Advisory

This advisory has been withdrawn because it is a duplicate of GHSA-ppx3-28rw-8fpf. This link is maintained to preserve external references.

Original Description

A vulnerability was detected in universal-tool-calling-protocol python-utcp 1.1.0. This affects an unknown function of the component utcp-gql/utcp-websocket. Performing a manipulation results in server-side request forgery. The attack can be initiated remotely. The exploit is now public and may be used. The vendor was contacted early about this disclosure but did not respond in any way.

A vulnerability was detected in universal-tool-calling-protocol python-utcp 1.1.0. This affects an unknown function of the component utcp-gql/utcp-websocket. Performing a manipulation results in server-side request forgery. The attack can be initiated remotely. The exploit is now public and may be used. The vendor was contacted early about this disclosure but did not respond in any way.

Summary

The fix for CVE-2026-44661 (commit 5b16e43) added the ensure_secure_url() / is_secure_url() helpers and wired them into the three HTTP-family plugins, but it did not reach the GraphQL or WebSocket plugins. The GraphQL plugin (utcp-gql) still uses the startswith prefix check that the fix explicitly replaced, so http://127.0.0.1.attacker.example and http://localhost.evil.com pass it. The WebSocket plugin (utcp-websocket) performs no URL validation at all, even though its own docstrings state it enforces "WSS or localhost only." Both plugins reach the same SSRF that CVE-2026-44661 was filed for, and because both attach the call template's configured auth headers to the outbound connection, the SSRF can also leak API keys and OAuth tokens to an attacker-controlled host.

Details

In the CVE-2026-44661 fix (commit 5b16e43 ("fix(http): block SSRF via attacker-controlled OpenAPI servers[0].url")), two things in it pointed at sibling issues. The commit message says the change is "replacing the duplicated prefix check", and the new utcp_http/_security.py docstring names the exact bug:

URLs whose hostname starts with localhost / 127.0.0.1 but isn't actually loopback (e.g. http://localhost.evil.com, http://127.0.0.1.attacker.example). The earlier startswith check let these through.

The word "duplicated" says the vulnerable check existed in more than one place. The fix only updated the three HTTP-family plugins (http, streamable_http, sse). The other communication-protocol plugins were also inspected.

GraphQL plugin (utcp-gql). plugins/communication_protocols/gql/src/utcp_gql/gql_communication_protocol.py still has the pre-fix check at line 43:

def _enforce_https_or_localhost(self, url: str) -> None:
    if not (
        url.startswith("https://")
        or url.startswith("http://localhost")
        or url.startswith("http://127.0.0.1")
    ):
        raise ValueError("Security error: URL must use HTTPS or start with ...")

It is called on manual_call_template.url in register_manual (line 102) and on tool_call_template.url in call_tool (line 181). The URL then goes into AIOHTTPTransport(url=...) and a live GraphQL request.

"http://127.0.0.1.attacker.example/graphql".startswith("http://127.0.0.1") is True, so the check passes. If the attacker controls DNS for attacker.example, that hostname resolves to any address they choose, including 169.254.169.254, 127.0.0.1, or an internal 192.168.x.x host, and the GraphQL client sends a plain-HTTP request there. http://localhost.evil.com/graphql behaves the same way. This is the exact prefix bypass CVE-2026-44661 was filed for.

WebSocket plugin (utcp-websocket). plugins/communication_protocols/websocket/src/utcp_websocket/websocket_communication_protocol.py. The module and class docstrings state:

"Security enforcement (WSS or localhost only)" "Enforces security by requiring WSS or localhost connections" "Security validation of connection URLs"

There is no such validation in the code. _get_connection(), the only connection path (used by register_manual, call_tool, and call_tool_streaming), calls:

ws = await session.ws_connect(call_template.url, headers=headers, ...)   # line 197

with no scheme or host check. Any URL in a WebSocketCallTemplate connects, including ws://169.254.169.254/, ws://127.0.0.1:<internal-port>/, or any internal hostname.

Credential exposure. Both plugins build connection headers in _prepare_headers(), which attaches the configured auth: ApiKeyAuth as a header, BasicAuth as an Authorization: Basic header, and OAuth2Auth as an Authorization: Bearer token. When the bypass is used to force a plain-HTTP or plain-WS connection to an attacker-resolved host, those credentials are sent to the attacker.

This is the threat model CVE-2026-44661 already established: a UTCP client ingests tool manuals, and a malicious…

Duplicate Advisory

This advisory has been withdrawn because it is a duplicate of GHSA-ppx3-28rw-8fpf. This link is maintained to preserve external references.

Original Description

A vulnerability was detected in universal-tool-calling-protocol python-utcp 1.1.0. This affects an unknown function of the component utcp-gql/utcp-websocket. Performing a manipulation results in server-side request forgery. The attack can be initiated remotely. The exploit is now public and may be used. The vendor was contacted early about this disclosure but did not respond in any way.

Summary

The fix for CVE-2026-44661 (commit 5b16e43) added the ensure_secure_url() / is_secure_url() helpers and wired them into the three HTTP-family plugins, but it did not reach the GraphQL or WebSocket plugins. The GraphQL plugin (utcp-gql) still uses the startswith prefix check that the fix explicitly replaced, so http://127.0.0.1.attacker.example and http://localhost.evil.com pass it. The WebSocket plugin (utcp-websocket) performs no URL validation at all, even though its own docstrings state it enforces "WSS or localhost only." Both plugins reach the same SSRF that CVE-2026-44661 was filed for, and because both attach the call template's configured auth headers to the outbound connection, the SSRF can also leak API keys and OAuth tokens to an attacker-controlled host.

Details

In the CVE-2026-44661 fix (commit 5b16e43 ("fix(http): block SSRF via attacker-controlled OpenAPI servers[0].url")), two things in it pointed at sibling issues. The commit message says the change is "replacing the duplicated prefix check", and the new utcp_http/_security.py docstring names the exact bug:

URLs whose hostname starts with localhost / 127.0.0.1 but isn't actually loopback (e.g. http://localhost.evil.com, http://127.0.0.1.attacker.example). The earlier startswith check let these through.

The word "duplicated" says the vulnerable check existed in more than one place. The fix only updated the three HTTP-family plugins (http, streamable_http, sse). The other communication-protocol plugins were also inspected.

GraphQL plugin (utcp-gql). plugins/communication_protocols/gql/src/utcp_gql/gql_communication_protocol.py still has the pre-fix check at line 43:

def _enforce_https_or_localhost(self, url: str) -> None:
    if not (
        url.startswith("https://")
        or url.startswith("http://localhost")
        or url.startswith("http://127.0.0.1")
    ):
        raise ValueError("Security error: URL must use HTTPS or start with ...")

It is called on manual_call_template.url in register_manual (line 102) and on tool_call_template.url in call_tool (line 181). The URL then goes into AIOHTTPTransport(url=...) and a live GraphQL request.

"http://127.0.0.1.attacker.example/graphql".startswith("http://127.0.0.1") is True, so the check passes. If the attacker controls DNS for attacker.example, that hostname resolves to any address they choose, including 169.254.169.254, 127.0.0.1, or an internal 192.168.x.x host, and the GraphQL client sends a plain-HTTP request there. http://localhost.evil.com/graphql behaves the same way. This is the exact prefix bypass CVE-2026-44661 was filed for.

WebSocket plugin (utcp-websocket). plugins/communication_protocols/websocket/src/utcp_websocket/websocket_communication_protocol.py. The module and class docstrings state:

"Security enforcement (WSS or localhost only)" "Enforces security by requiring WSS or localhost connections" "Security validation of connection URLs"

There is no such validation in the code. _get_connection(), the only connection path (used by register_manual, call_tool, and call_tool_streaming), calls:

ws = await session.ws_connect(call_template.url, headers=headers, ...)   # line 197

with no scheme or host check. Any URL in a WebSocketCallTemplate connects, including ws://169.254.169.254/, ws://127.0.0.1:<internal-port>/, or any internal hostname.

Credential exposure. Both plugins build connection headers in _prepare_headers(), which attaches the configured auth: ApiKeyAuth as a header, BasicAuth as an Authorization: Basic header, and OAuth2Auth as an Authorization: Bearer token. When the bypass is used to force a plain-HTTP or plain-WS connection to an attacker-resolved host, those credentials are sent to the attacker.

This is the threat model CVE-2026-44661 already established: a UTCP client ingests tool manuals, and a malicious…

Summary

The fix for CVE-2026-44661 (commit 5b16e43) added the ensure_secure_url() / is_secure_url() helpers and wired them into the three HTTP-family plugins, but it did not reach the GraphQL or WebSocket plugins. The GraphQL plugin (utcp-gql) still uses the startswith prefix check that the fix explicitly replaced, so http://127.0.0.1.attacker.example and http://localhost.evil.com pass it. The WebSocket plugin (utcp-websocket) performs no URL validation at all, even though its own docstrings state it enforces "WSS or localhost only." Both plugins reach the same SSRF that CVE-2026-44661 was filed for, and because both attach the call template's configured auth headers to the outbound connection, the SSRF can also leak API keys and OAuth tokens to an attacker-controlled host.

Details

In the CVE-2026-44661 fix (commit 5b16e43 ("fix(http): block SSRF via attacker-controlled OpenAPI servers[0].url")), two things in it pointed at sibling issues. The commit message says the change is "replacing the duplicated prefix check", and the new utcp_http/_security.py docstring names the exact bug:

URLs whose hostname starts with localhost / 127.0.0.1 but isn't actually loopback (e.g. http://localhost.evil.com, http://127.0.0.1.attacker.example). The earlier startswith check let these through.

The word "duplicated" says the vulnerable check existed in more than one place. The fix only updated the three HTTP-family plugins (http, streamable_http, sse). The other communication-protocol plugins were also inspected.

GraphQL plugin (utcp-gql). plugins/communication_protocols/gql/src/utcp_gql/gql_communication_protocol.py still has the pre-fix check at line 43:

def _enforce_https_or_localhost(self, url: str) -> None:
    if not (
        url.startswith("https://")
        or url.startswith("http://localhost")
        or url.startswith("http://127.0.0.1")
    ):
        raise ValueError("Security error: URL must use HTTPS or start with ...")

It is called on manual_call_template.url in register_manual (line 102) and on tool_call_template.url in call_tool (line 181). The URL then goes into AIOHTTPTransport(url=...) and a live GraphQL request.

"http://127.0.0.1.attacker.example/graphql".startswith("http://127.0.0.1") is True, so the check passes. If the attacker controls DNS for attacker.example, that hostname resolves to any address they choose, including 169.254.169.254, 127.0.0.1, or an internal 192.168.x.x host, and the GraphQL client sends a plain-HTTP request there. http://localhost.evil.com/graphql behaves the same way. This is the exact prefix bypass CVE-2026-44661 was filed for.

WebSocket plugin (utcp-websocket). plugins/communication_protocols/websocket/src/utcp_websocket/websocket_communication_protocol.py. The module and class docstrings state:

"Security enforcement (WSS or localhost only)" "Enforces security by requiring WSS or localhost connections" "Security validation of connection URLs"

There is no such validation in the code. _get_connection(), the only connection path (used by register_manual, call_tool, and call_tool_streaming), calls:

ws = await session.ws_connect(call_template.url, headers=headers, ...)   # line 197

with no scheme or host check. Any URL in a WebSocketCallTemplate connects, including ws://169.254.169.254/, ws://127.0.0.1:<internal-port>/, or any internal hostname.

Credential exposure. Both plugins build connection headers in _prepare_headers(), which attaches the configured auth: ApiKeyAuth as a header, BasicAuth as an Authorization: Basic header, and OAuth2Auth as an Authorization: Bearer token. When the bypass is used to force a plain-HTTP or plain-WS connection to an attacker-resolved host, those credentials are sent to the attacker.

This is the threat model CVE-2026-44661 already established: a UTCP client ingests tool manuals, and a malicious…