CVE-2026-101060 in python-utcp
Summary
by MITRE • 09/27/2026
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.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 09/27/2026
The vulnerability identified in python-utcp versions prior to 1.1.4 represents a critical server-side request forgery flaw within the HttpCommunicationProtocol.call_tool method. This issue stems from an incomplete validation of Uniform Resource Locators during HTTP communication processes. While the implementation correctly validates the initial URL provided by the caller, it fails to apply equivalent security checks when following automatic redirects issued by the target server. In standard web client behavior, a 302 Found status code instructs the user agent or library to fetch the resource located at the URI specified in the Location header. The flaw lies in the fact that python-utcp does not re-validate this new destination URL against any allowlists or security policies before proceeding with the request and returning the response body to the original caller.
This architectural oversight allows an attacker who controls a tool endpoint, which is invoked by the UTCP client, to manipulate the redirect behavior for malicious purposes. By configuring their service to return a 302 redirect pointing toward internal network resources or cloud metadata endpoints, the attacker can force the vulnerable library to make requests that would otherwise be inaccessible from its execution context. Common targets include instance metadata services such as AWS EC2 Instance Metadata Service (IMDS) at addresses like 169.254.169.254, which contain sensitive authentication credentials and configuration data for cloud instances. Additionally, internal HTTP services running on localhost or private network ranges can be accessed, potentially exposing proprietary APIs, administrative interfaces, or database connections that are not intended to be reachable from the external-facing tool endpoint.
The operational impact of this vulnerability is severe, as it effectively bypasses network segmentation and access control mechanisms designed to isolate cloud workloads and internal services. An attacker leveraging this flaw can exfiltrate sensitive data such as temporary security credentials, IAM roles, or private keys stored in metadata endpoints. Furthermore, by accessing internal HTTP services, the attacker may be able to perform unauthorized actions within the internal network, leading to further compromise of the infrastructure. This behavior aligns with CWE-918, which classifies Server-Side Request Forgery (SSRF) as a weakness where a web server fetches a remote resource without validating the user-supplied URL. The specific mechanism here also relates to CWE-436, Interpretation Error, where the system fails to correctly interpret the security implications of following redirects from untrusted sources.
From an offensive security perspective, this vulnerability maps directly to MITRE ATT&CK technique T1557, Adversary-in-the-Middle, specifically under the sub-technique for Lateral Tool Transfer or credential access via cloud metadata services. It also relates to T1098, Account Manipulation, if used to exfiltrate credentials that allow further account compromise. The lack of redirect validation is a common pattern in older HTTP client implementations and highlights the importance of strict URL verification at every hop in a request chain rather than just at the initial entry point.
To mitigate this vulnerability, organizations must upgrade python-utcp to version 1.1.4 or later, where the issue has been addressed by implementing proper redirect validation logic. In environments where upgrading is not immediately feasible, defensive measures should include configuring the HTTP client library to disable automatic redirects entirely if they are not strictly required for business functionality. Alternatively, developers can implement a custom redirect handler that validates each new URL against a strict allowlist of permitted domains and IP ranges before proceeding with the request. Network-level controls such as firewall rules blocking outbound access to cloud metadata endpoints or internal service IPs from the host running python-utcp provide an additional layer of defense in depth. Regular security audits focusing on HTTP client usage patterns are recommended to identify similar misconfigurations across other components of the application stack.