GHSA-r8j5-8747-88cm @utcp/http: SSRF via attacker-controlled OpenAPI servers[0].url in HTTP communication protocol
SummaryThe `@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 advisoryThis is the npm/TypeScript counterpart of [GHSA-39j6-4867-gg4w / CVE-2026-44661](https://github.com/universal-tool-calling-protocol/python-utcp/security/advisories/GHSA-39j6-4867-gg4w) 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.ImpactA 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.PatchCommit 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.WorkaroundsFor 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.CreditDiscovered and reported by [@YLChen-007](https://github.com/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.
CVSS v3.1 score: 4.7