Executive brief
The utcp-http library's HTTP communication protocol validates tool endpoint URLs before making requests, but fails to re-validate redirect targets. An attacker who controls a tool endpoint or compromises a legitimate one can return a 302 redirect pointing to internal services (such as cloud metadata endpoints), allowing the library to fetch and return sensitive data like IAM credentials. On cloud instances with IMDSv1 enabled, this directly compromises infrastructure; more broadly it reaches internal admin panels, datastores, and other unauthenticated services that should be unreachable.
Technical details
The vulnerability lies in `HttpCommunicationProtocol.call_tool`, which validates tool endpoint URLs via `ensure_secure_url` before making an HTTP request but then makes the request with aiohttp's default `allow_redirects=True` without re-validating each redirect hop. An attacker who controls the tool endpoint (either because the registered URL is attacker-influenced—such as a manually or OpenAPI spec discovered from a runtime-supplied URL—or because a legitimate endpoint is compromised) can return a 3xx redirect with a Location header pointing to an internal service. The initial URL only needs to pass validation (any HTTPS URL or a benign attacker-owned host); the actual attack happens on the redirect. The response body from the internal service is then returned to the tool caller, enabling exfiltration. On cloud instances with IMDSv1, this directly yields instance IAM credentials; IMDSv2-only hosts are protected against credential theft but remain vulnerable to other internal SSRF attacks. The fix, available in utcp-http 1.1.4, disables automatic redirects and validates each hop against `ensure_secure_url` before following, capping redirect chains at 5 hops.
Affected products
- universal-tool-calling-protocol utcp-http <= 1.1.3
Timeline
- 2026-06-14: disclosed
- 2026-08-25: patched: Fixed in utcp-http 1.1.4 and @utcp/http 1.1.4 (TypeScript)
- 2026-08-25: advisory