Description

utcp-http before 1.1.4 fails to validate the OAuth2 tokenUrl field from remote OpenAPI specifications, allowing attackers to redirect credential submission to arbitrary endpoints. When a victim registers an attacker-controlled OpenAPI spec and invokes a generated OAuth2-protected tool, the library POSTs the victim's client_id and client_secret to the attacker-supplied token endpoint without URL validation.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.1",
  "pubDate": "2026-09-27T18:16:32.130Z",
  "pubdate": "2026-09-27T18:16:32.130Z",
  "executiveSummary": "The utcp-http library, in versions prior to 1.1.4, contains an improper input validation vulnerability within its OpenAPI specification processing module. Specifically, the library fails to sanitize or validate the 'tokenUrl' field defined within remote OpenAPI specifications. This flaw allows an attacker to manipulate the authentication flow by providing an arbitrary, attacker-controlled URL as the OAuth2 token endpoint.\nThe vulnerability poses a significant risk to confidentiality, as it facilitates the unauthorized exfiltration of sensitive credentials. By registering a malicious OpenAPI specification, an attacker can coerce the library into transmitting a victim's OAuth2 'client_id' and 'client_secret' directly to an external endpoint of the attacker's choosing. This bypasses expected security controls by masquerading as a legitimate authentication request. The exploit requires user interaction, specifically the registration of the malicious spec and the subsequent invocation of an OAuth2-protected tool generated from it. Successful exploitation results in the compromise of API credentials, potentially granting the attacker unauthorized access to protected third-party resources or services associated with the victim's account.\nGiven the nature of OpenAPI integration in automated workflows, this vulnerability presents a high risk to systems that consume remote, untrusted specifications.",
  "technicalDetails": "The vulnerability originates from a lack of server-side validation regarding the 'tokenUrl' parameter during the parsing and processing of OpenAPI specification files in utcp-http. The library treats the 'tokenUrl' value as a trusted parameter, failing to enforce domain whitelisting, scheme verification, or protocol constraints.\nThe attack flow begins when an attacker crafts a malicious OpenAPI specification document containing a target-specified 'tokenUrl' that points to an adversary-controlled server. This document is provided to the victim or an automated system that uses the utcp-http library to register OpenAPI tools. Upon registration, the library parses the specification and initializes the OAuth2 client configuration using the attacker-supplied URL.\nThe exploitation occurs when a victim invokes a tool generated from this malicious specification. When the library attempts to perform the OAuth2 authorization flow, it initiates an HTTP POST request to the attacker-defined 'tokenUrl'. Because the library lacks validation logic to ensure the endpoint resides within an authorized or expected infrastructure, it blindly includes the victim's sensitive 'client_id' and 'client_secret' in the body of the POST request. This transmission occurs automatically as part of the tool's standard execution lifecycle.\nThe vulnerable component is the OpenAPI specification handler within the utcp-http library. The failure exists specifically in the logic responsible for mapping the 'tokenUrl' definition from the OpenAPI document to the underlying HTTP client configuration. Any version of utcp-http prior to 1.1.4 is susceptible to this manipulation.\nFrom a network perspective, the library will establish an outbound connection to the attacker's server whenever the affected tool is triggered. The attacker, operating the remote endpoint, captures the POST request, thereby obtaining the valid credentials for the OAuth2 application. This is a classic example of a credential exfiltration vulnerability facilitated by improper trust in configuration data. The post-exploitation impact includes the full compromise of the impacted OAuth2 client application, allowing the attacker to assume the identity of the client in subsequent interactions with the target service provider. The exploit does not require the attacker to have administrative privileges on the victim's machine; it only requires the victim to consume the malicious specification."
}