Summary
python-utcp contains a server-side request forgery vulnerability in its HTTP communication protocol because redirect destinations are not revalidated. An attacker controlling a tool endpoint may redirect the client to cloud metadata services or internal HTTP systems and expose their response bodies to the caller.
Affected context
The issue occurs in deployments using python-utcp's HttpCommunicationProtocol.call_tool to contact tool endpoints over HTTP. It becomes risky when a client can reach attacker-controlled or otherwise untrusted endpoints and the HTTP client follows redirects without applying the original URL validation policy to each destination.
Exploit preconditions
- Attack surface: HTTP tool communication performed by the UTCP client
- Required access: Ability to operate, influence, or compromise a tool endpoint selected by the client
- Trigger point: Processing an HTTP redirect returned during
call_tool - Why exploitation is possible: The initial URL is validated, but the redirected destination is trusted without equivalent validation, allowing requests to reach internal or otherwise restricted services
Why this happens
The vulnerability results from incomplete URL validation across an HTTP redirect chain. Validating only the initial destination creates a trust boundary gap because a server can direct the client to a different host, address range, scheme, or port after validation has completed. This maps to CWE-918: Server-Side Request Forgery, where server-side functionality can be induced to send requests to unintended destinations.
Potential impact
- Internal service responses may be disclosed to an external caller
- Cloud instance metadata or temporary credentials could be exposed
- Internal APIs may be reached from a network position the attacker cannot access directly
- Network reconnaissance or service interaction could occur through the UTCP client
- Sensitive response bodies may be returned to the tool caller
General mitigation guidance
Mitigation generally focuses on treating every redirect destination as untrusted and enforcing destination policy throughout the request lifecycle.
Common defensive patterns include:
- Revalidating every redirect target against an explicit host, scheme, port, and network-range policy
- Disabling automatic redirects by default when they are not required
- Preferencing allowlists of approved tool endpoints over broad URL acceptance
- Blocking loopback, link-local, private, and cloud-metadata address ranges where access is not necessary
- Restricting outbound network permissions for UTCP clients through egress controls
- Running clients with only the network and identity privileges required for their intended tools
- Reducing response exposure by returning only the minimum data required by the calling workflow
These controls reduce reliance on the initial URL validation and limit the consequences of an unexpected destination.
How teams detect issues like this
High-level detection can include:
- Static analysis rules for HTTP clients that validate URLs before requests but not after redirects
- Code review checks for automatic redirect following, destination changes, and DNS or IP-range validation
- Tests covering redirects to loopback, private, link-local, metadata, alternate-port, and scheme-changing destinations
- Egress firewall or proxy policies that alert on client requests to restricted address ranges
- Runtime monitoring of outbound requests and unusual response retrieval from internal services
Automated security review tools may help identify redirect handling paths that bypass SSRF protections.
