CVE-2026-44661

The utcp-http plugin is vulnerable to a blind Server-Side Request Forgery (SSRF) caused by a trust-boundary inconsistency between manual discovery and tool invocation. register_manual() validates the discovery URL against an HTTPS / loopback allowlist, but call_tool() and call_tool_streaming() reuse the resolved tool_call_template.url directly without revalidating. An attacker who hosts a malicious OpenAPI spec on a legitimate HTTPS endpoint can declare servers: [{ url: "http://169.254.169.254" }] (or any internal address) in the spec; the OpenAPI converter blindly trusts that value and the tool becomes a blind SSRF primitive that exposes cloud metadata, internal services, and other firewalled-only endpoints to the LLM caller.

All three HTTP-class protocols (utcp_http.http, utcp_http.streamable_http, utcp_http.sse) shared the same gap, plus a separate prefix-bypass: the previous startswith("http://localhost") check let URLs like http://localhost.evil.com through.

Affected versions

utcp-http <= 1.1.1.

Patched versions

utcp-http 1.1.2.

Workarounds

For users who cannot upgrade immediately:

• Refuse to call register_manual with any URL controlled by an untrusted party, even over HTTPS.
• Restrict outbound network access from the host running the agent so internal addresses (RFC1918, 169.254.0.0/16, loopback for cloud metadata) are unreachable.

Credit

Discovered and reported by @YLChen-007 in #83.

A remote attacker who can convince the agent (via the LLM context, prompt injection, or a tool-discovery surface) to register their HTTPS OpenAPI URL can:

• Map internal networks behind the agent.
• Read AWS/GCP IAM credentials from cloud metadata endpoints (http://169.254.169.254, http://metadata.google.internal).
• Reach unauthenticated internal services (Elasticsearch, Redis HTTP, internal admin panels).
• Have responses returned to the LLM, which combined with prompt injection enables exfiltration back to the attacker.

Untrusted input controls the target URL of a server-initiated request, which may reach internal services not otherwise accessible from outside. Typical impact: access to internal metadata services, internal APIs, or cloud credentials.

CVE-2026-44661 has a CVSS score of 4.7 (Medium). The vector is network-reachable, no privileges required, and user interaction required. A CVSS score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether this affects your application depends on whether the vulnerable code is present and reachable in your environment. A fixed version is available (1.1.2); upgrading removes the vulnerable code path.

Kodem intelligence

Commit: 5b16e43 on dev.

• New utcp_http._security helper: ensure_secure_url(url, context=...) parses the URL with urllib.parse.urlparse and validates the hostname (not a string prefix) against the loopback set, closing the localhost.evil.com bypass.
• All three protocols call ensure_secure_url(url, context="manual discovery") in register_manual (replacing the duplicated prefix check) and ensure_secure_url(url, context="tool invocation") immediately before each aiohttp request in call_tool / call_tool_streaming. The runtime check is the actual SSRF fix.
• New regression tests in test_security.py pin the accept/reject decisions and explicitly cover the historical bypass cases.

1. What is CVE-2026-44661? CVE-2026-44661 is a medium-severity server-side request forgery (SSRF) vulnerability in utcp-http (pip), affecting versions <= 1.1.1. It is fixed in 1.1.2. Untrusted input controls the target URL of a server-initiated request, which may reach internal services not otherwise accessible from outside.
2. How severe is CVE-2026-44661? CVE-2026-44661 has a CVSS score of 4.7 (Medium). This score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether it represents real risk in your environment depends on whether the vulnerable code is present and reachable.
3. Which versions of utcp-http are affected by CVE-2026-44661? utcp-http (pip) versions <= 1.1.1 is affected.
4. Is there a fix for CVE-2026-44661? Yes. CVE-2026-44661 is fixed in 1.1.2. Upgrade to this version or later.
5. Is CVE-2026-44661 exploitable, and should I be worried? Whether CVE-2026-44661 is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
6. What actually determines whether CVE-2026-44661 is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
7. How do I fix CVE-2026-44661? Upgrade utcp-http to 1.1.2 or later.