Description

python-utcp versions before 1.1.4 contain a server-side request forgery vulnerability in HttpCommunicationProtocol.call_tool that validates the initial tool URL but follows HTTP redirects without re-validating the target. Attackers controlling a tool endpoint can return a 302 redirect to internal services, allowing the UTCP client to reach cloud metadata endpoints or internal HTTP services and return their response bodies to the caller.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "8.2",
  "pubDate": "2026-09-27T18:16:32.273Z",
  "pubdate": "2026-09-27T18:16:32.273Z",
  "executiveSummary": "A Server-Side Request Forgery (SSRF) vulnerability exists in the python-utcp library due to improper validation of redirected HTTP requests.\nThe vulnerability affects versions prior to 1.1.4, specifically within the HttpCommunicationProtocol.call_tool method.\nThe flaw allows an attacker to bypass initial URL validation by leveraging HTTP 302 redirects.\nBy controlling a malicious tool endpoint, an attacker can coerce the library to interact with internal services, including cloud metadata endpoints or private HTTP-based infrastructure.\nSuccessful exploitation enables unauthorized access to sensitive internal data, potentially leading to information disclosure or further exploitation of local services.\nThis vulnerability poses a significant risk to systems that process untrusted tool URLs, as the attack requires only the ability to provide an attacker-controlled endpoint that initiates a redirect to a forbidden target.\nThe impact is elevated in cloud environments where sensitive metadata services are reachable via internal network segments.",
  "technicalDetails": "The vulnerability resides in the HttpCommunicationProtocol.call_tool function of the python-utcp library, which fails to enforce security constraints on HTTP redirects.\nThe root cause is an insecure implementation of request redirection: while the initial URL provided to call_tool is subject to a validation check, the subsequent requests initiated by the library following a 302 redirect are not subjected to the same security verification processes.\nIn a typical attack flow, the attacker provides a URL for a tool endpoint under their control. When the HttpCommunicationProtocol library initiates the request to this tool, the attacker's server responds with an HTTP 302 'Found' status code, including a 'Location' header pointing to a restricted destination, such as 'http://169.254.169.254/' (a common cloud metadata service) or an internal microservice.\nBecause the library automatically follows the redirect without re-validating the newly provided URL, the underlying HTTP client performs a request to the sensitive internal target as if it were a legitimate part of the tool communication flow.\nThe response from the internal service is then captured by the library and returned to the caller, effectively leaking private data back to the attacker.\nThe vulnerability is present in all python-utcp versions prior to 1.1.4. Exploitation does not require authentication to the target application, as the attack is triggered by the application's own request-handling logic when it interacts with an attacker-provided URL.\nThe primary risk is the bypass of network-level security controls, as the library operates from within the application's security context, allowing it to bypass firewalls or Network Security Groups that would otherwise prevent the attacker from directly accessing internal resources.\nPost-exploitation impact includes the potential exfiltration of instance metadata (including security credentials, identity tokens, or configuration information), scanning of internal network segments, or interacting with RESTful administrative APIs that do not require additional authentication."
}