CVE-2026-45366

The @utcp/http package is vulnerable to a blind Server-Side Request Forgery (SSRF) caused by a trust-boundary inconsistency between manual discovery and tool invocation. registerManual() validates the discovery URL against an HTTPS / loopback allowlist, but callTool() reuses the resolved toolCallTemplate.url directly without revalidating, and the OpenApiConverter blindly trusts whatever servers[0].url an attacker-hosted spec declares. An attacker who hosts a malicious OpenAPI spec on a legitimate HTTPS endpoint can declare e.g. servers: [{ url: "http://127.0.0.1:9090" }] or servers: [{ url: "http://169.254.169.254" }]; the converter then produces tools whose URL points at internal services on the agent host.

A separate prefix-bypass also affected the discovery-time check: the previous startsWith('http://localhost') guard let URLs like http://localhost.evil.com through.

Sister advisory

This is the npm/TypeScript counterpart of GHSA-39j6-4867-gg4w / CVE-2026-44661 on the Python utcp-http package. Same vulnerability, same fix shape, same reporter.

Versions and patch state

• @utcp/http <= 1.1.1, vulnerable. Both the loopback-redirect (http://127.0.0.1) and the non-loopback internal-IP variants (e.g. http://169.254.169.254, http://10.0.0.5) succeed. Note: the streamable_http and sse callToolStreaming paths in 1.1.1 are TODO placeholders and don't actually fetch URLs, so the runtime SSRF surface in these protocols is currently confined to discovery, a future implementation must also call ensureSecureUrl before issuing the request.
• @utcp/http 1.1.2, full fix. Runtime revalidation in callTool closes the non-loopback variants; the OpenApiConverter rejects, at conversion time, any spec fetched from a non-loopback source that declares a loopback servers[0].url, closing the loopback-redirect variant.

Workarounds

For users who cannot upgrade immediately:

• Refuse to call registerManual 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) are unreachable.

Credit

Discovered and reported by @YLChen-007 against the Python sibling implementation (universal-tool-calling-protocol/python-utcp#83). The TypeScript port shared the same code shape and the same vulnerability.

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 exposed on loopback (Elasticsearch, Redis HTTP, internal admin panels, the agent's own HTTP server).
• 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-45366 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 on dev: 21f63e6.

New helper packages/http/src/_security.ts exposes isSecureUrl, isLoopbackUrl, ensureSecureUrl. Hostname-based validation closes the prefix bypass (http://localhost.evil.com → rejected). All three protocols' registerManual now call ensureSecureUrl(url, 'manual discovery'); callTool re-checks the resolved URL with ensureSecureUrl(url, 'tool invocation') immediately before the axios request. OpenApiConverter rejects remote spec → loopback server.

1. What is CVE-2026-45366? CVE-2026-45366 is a medium-severity server-side request forgery (SSRF) vulnerability in @utcp/http (npm), 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-45366? CVE-2026-45366 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-45366? @utcp/http (npm) versions <= 1.1.1 is affected.
4. Is there a fix for CVE-2026-45366? Yes. CVE-2026-45366 is fixed in 1.1.2. Upgrade to this version or later.
5. Is CVE-2026-45366 exploitable, and should I be worried? Whether CVE-2026-45366 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-45366 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-45366? Upgrade @utcp/http to 1.1.2 or later.