CVE-2026-45366: @utcp/http Blind SSRF via OpenAPI Spec Trust-Boundary Flaw

Technical summary

The vulnerability arises from a trust-boundary inconsistency in typescript-utcp's @utcp/http package. The registerManual() function validates discovery URLs against an allowlist (HTTPS or loopback), but callTool() reuses the resolved toolCallTemplate.url without revalidating it. Additionally, the OpenApiConverter accepts server URLs directly from OpenAPI specifications without validation. When processing an attacker-hosted OpenAPI spec, the converter blindly trusts the servers[0].url field. An attacker can craft a spec with servers: [{ url: "http://127.0.0.1:9090" }] or similar loopback/RFC 1918 addresses to cause the agent to generate tools pointing at internal services. The vulnerability is classified as CWE-918 (Server-Side Request Forgery) and does not require authentication or user interaction beyond the initial hosting of the malicious spec on an HTTPS endpoint.

Business impact

This SSRF vulnerability could allow attackers to enumerate and interact with internal services running on the agent host or within its network segment. An attacker could probe for configuration APIs, metadata services (such as AWS IMDSv1 endpoints), internal databases, or administrative interfaces. While the CVSS score of 4.7 reflects moderate severity, the actual impact depends on what internal services are exposed and their security posture. For organizations using @utcp/http in agent or LLM-integration contexts, this could lead to credential theft, information disclosure, or lateral movement if internal services lack proper access controls or run in privileged contexts.

Affected systems

The @utcp/http package in typescript-utcp versions prior to 1.1.2 is affected. Organizations using this package for OpenAPI-based tool invocation, particularly in agent architectures or automated API orchestration scenarios, should assess their exposure. The vulnerability requires an attacker to control or influence the OpenAPI specification being processed, which is most feasible in scenarios where agents dynamically load external or user-supplied specifications.

Exploitability

Exploitation requires moderate complexity: an attacker must host a malicious OpenAPI specification on a legitimate HTTPS endpoint and ensure the vulnerable application processes it. User interaction is required in the sense that a user or agent must invoke tool calling with the attacker-controlled spec. The attack surface is conditional on whether the application fetches and processes external OpenAPI specs without strict origin validation. Once a malicious spec is processed, the SSRF payload is triggered automatically when tools are invoked, making post-exploitation straightforward.

Remediation

Upgrade @utcp/http to version 1.1.2 or later, which addresses the trust-boundary inconsistency by enforcing consistent URL validation across both manual registration and tool invocation pathways. Additionally, implement network-level controls: restrict egress from application processes to only necessary external services, block internal IP ranges at the application layer, and consider disabling access to metadata service endpoints (169.254.169.254 for AWS) unless explicitly required. Review any deployment where external or dynamically sourced OpenAPI specs are processed.

Patch guidance

Apply the upgrade to @utcp/http 1.1.2 or later as soon as practical. Verify the upgrade against the typescript-utcp project repository or vendor advisory to confirm version availability and any dependency updates required. Regenerate and redeploy any container images or artifacts that bundle this package. If immediate patching is not feasible, implement compensating controls such as network segmentation or OpenAPI spec pinning (only loading specs from trusted, immutable sources).

Detection guidance

Monitor for outbound HTTP/HTTPS connections from @utcp/http processes to unusual or internal destinations, particularly to loopback addresses (127.0.0.1) or RFC 1918 ranges not normally accessed by the application. Log all OpenAPI spec retrieval and parsing events, flagging specs fetched from unexpected sources. Network-level detection: alert on requests to 169.254.169.254 (AWS metadata) or similar reserved addresses originating from application servers. If available, enable debug logging in typescript-utcp to trace the servers[0].url resolution and compare against expected allowlists.

Why prioritize this

While the CVSS score is moderate (4.7), prioritization should reflect whether the organization processes untrusted or externally sourced OpenAPI specifications. If your deployment loads specs only from internal, curated sources, risk is lower. If specs are dynamically retrieved, user-supplied, or sourced from third parties, prioritization should be elevated. The fact that this is not yet in CISA's KEV catalog does not diminish urgency for affected deployments; patching is straightforward and recommended within a standard maintenance window.

Risk score, explained

The CVSS 3.1 score of 4.7 (MEDIUM) reflects: Network attack vector (no direct system access needed), High attack complexity (attacker must host spec and ensure processing), No privilege requirements, User interaction required (spec must be invoked), and Changed scope (affects other systems via SSRF). The score does not assume exploitation difficulty in real-world contexts where agent architectures routinely fetch external specifications. Organizations with higher reliance on dynamic OpenAPI loading should consider this a more acute risk than the base score suggests.

Frequently asked questions