Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
3 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
The utcp-http library (<= 1.1.3) unconditionally trusts the tokenUrl field embedded in remote OpenAPI security schemes. When a victim registers an attacker-controlled OpenAPI spec and invokes any generated OAuth2-protected tool, the library POSTs the victim's clientid and clientsecret to the attacker-supplied token endpoint without any URL validation. The same ensuresecureurl() guard applied to discovery URLs and tool invocation URLs is absent for the OAuth2 token endpoint, creating a credential-exfiltration path. Details utcp-http supports automatic tool generation from remote OpenAPI specifications. During conversion, OpenApiConverter.extractauth() reads OAuth2 flow configuration directly from the spec: The generated HttpCallTemplate carries this OAuth2Auth object. At call time, HttpCommunicationProtocol.handleoauth2() forwards credentials to that URL: By contrast, the discovery URL and the tool invocation URL are both validated before use: The ensuresecureurl() function…
Recommended action: Upgrade to 1.1.4 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
HttpCommunicationProtocol.calltool validates only the pre-redirect tool URL, then issues the request with redirects enabled and never re-checks where it lands. A tool whose endpoint is an attacker-controlled public URL can therefore 302-redirect the UTCP client into an internal service including the cloud metadata endpoint and the response body is returned to the tool caller. This is a working SSRF + internal-data-exfiltration primitive. This is the redirect invariant of the SSRF class fixed in GHSA-39j6-4867-gg4w; that fix added an invocation-time URL check but left the redirect hop unguarded. This vector bypasses the GHSA-39j6-4867-gg4w mitigation via unvalidated redirects. Root cause 1. The resolved URL is validated once, before the request: https://github.com/universal-tool-calling-protocol/python-utcp/blob/4ed0a48b84a452338bd3e996efb0d169e8d75ac2/plugins/communicationprotocols/http/src/utcphttp/httpcommunicationprotocol.py#L281 2. The request is then made with aiohttp's…
Recommended action: Upgrade to 1.1.4 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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. registermanual() validates the discovery URL against an HTTPS / loopback allowlist, but calltool() and calltoolstreaming() reuse the resolved toolcalltemplate.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 (utcphttp.http, utcphttp.streamablehttp, utcphttp.sse) shared the same gap, plus a separate prefix-bypass: the previous startswith("http://localhost") check let URLs like http://localhost.evil.com through. Impact A remote…
Recommended action: Upgrade to 1.1.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.