CVE-2026-101058 in utcp-http
Summary
by MITRE • 09/27/2026
python-utcp (pip package utcp-http) before 1.1.12 does not verify whether tool URLs declared in a hand-written UTCP manual point at the agent's own loopback interface when that manual is discovered from a remote, non-loopback origin. Because ensure_secure_url intentionally permits loopback HTTP for local development and native manuals bypassed the loopback check performed by the OpenAPI converter, an attacker who can serve a UTCP manual that a victim registers can cause the client to issue requests to services bound only to 127.0.0.1 on the victim host and have the response bodies returned to the caller (server-side request forgery). The http, sse and streamable_http protocols are all affected. Reach is limited to loopback, and exploitation further requires a loopback service that answers unauthenticated requests with useful data. Fixed in utcp-http 1.1.12, which rejects manuals fetched from a non-loopback origin that declare loopback tool URLs, keyed off the final post-redirect discovery URL.
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 prior to version 1.1.12 represents a significant server-side request forgery flaw rooted in improper validation of Uniform Tool Control Protocol manual sources and their declared endpoints. The core issue arises when the client processes UTCP manuals discovered from remote, non-loopback origins but containing tool URLs that point specifically to the agent's own loopback interface, typically 127.0.0.1 or localhost. This behavior contradicts standard security expectations where resources fetched from untrusted external sources should not be permitted to trigger local network requests without rigorous verification of their destination scope. The flaw is particularly insidious because it exploits a design decision intended for developer convenience rather than production security, allowing manual configurations that bypass critical safety checks under specific conditions.
The technical mechanism behind this vulnerability involves the ensure_secure_url function and its interaction with the OpenAPI converter logic. In local development environments, ensuring secure URLs intentionally permits loopback HTTP connections to facilitate testing against services running on the same machine. However, when a UTCP manual is fetched from a remote origin via http, sse, or streamable_http protocols, this permissive behavior becomes dangerous if not properly scoped. The OpenAPI converter used for processing these manuals inadvertently bypassed the standard loopback check that would normally restrict such requests. This oversight means that any tool URL declared within a manually authored UTCP specification is accepted without verifying whether it targets local infrastructure, effectively treating remote-sourced configurations with the same trust level as locally sourced ones.
The operational impact of this vulnerability allows an attacker to perform server-side request forgery attacks against services bound exclusively to the loopback interface on the victim host. Since these services are typically protected from external network access by firewall rules or binding constraints, they often assume that any incoming connection originates from a trusted local process and may therefore omit authentication checks. By serving a malicious UTCP manual that a victim registers with their client, an attacker can force the vulnerable application to issue requests to these internal endpoints. The response bodies from these unauthenticated queries are then returned to the caller, potentially exposing sensitive data such as configuration details, user information, or system status that was never intended for external consumption.
This attack vector is constrained by specific environmental requirements but remains highly effective in development and testing scenarios where loopback services lack authentication. Reach is limited strictly to the loopback interface, meaning the attacker cannot directly target arbitrary remote hosts through this flaw alone. Furthermore successful exploitation requires the presence of a vulnerable service on the victim's machine that responds to unauthenticated requests with useful data. Despite these limitations, the ability to exfiltrate internal state from protected services constitutes a serious confidentiality breach and highlights the risks associated with mixing local development convenience features into code paths accessible via remote inputs.
Mitigation strategies focus primarily on upgrading to utcp-http version 1.1.12 or later, where this issue has been resolved by enforcing stricter validation rules for manual sources. The fix ensures that manuals fetched from non-loopback origins are rejected if they declare loopback tool URLs, with the determination based on the final post-redirect discovery URL rather than just the initial request target. This approach closes the bypass vector created by redirects and ensures consistent security posture regardless of how the manual was discovered. Organizations should also review their internal services bound to 127.0.0.1 for proper authentication mechanisms, as defense in depth remains critical even when client-side vulnerabilities are patched.
From a classification perspective this vulnerability aligns with CWE-918 Server-Side Request Forgery and specifically relates to CWE-601 URL Redirection to Untrusted Site which can lead to security bypasses. In the context of the MITRE ATT&CK framework, this behavior facilitates T1557 Adversary-in-the-Middle or potentially T1046 Network Service Discovery depending on whether active scanning is involved, though it primarily serves as a data exfiltration channel via SSRF. The failure to validate resource origins against their intended scope reflects broader issues in input validation logic where contextual trust boundaries are not correctly maintained during processing pipelines.