CVE-2026-75523 in Steeltoe
Summary
by MITRE • 09/17/2026
Steeltoe is an open source project that provides a collection of libraries that helps users build cloud-native applications. Prior to 4.3.0, the Steeltoe.Management.Endpoint /actuator/httpexchanges endpoint passes recorded request URIs through MaskedUri, which masks URI user information but does not inspect query strings. When Management:Endpoints:HttpExchanges:IncludeQueryString is enabled, the HttpExchangeRequest response can disclose OAuth tokens, password-reset tokens, signed-URL signatures, API keys, and other query-string secrets from prior traffic to a caller that can reach the explicitly exposed endpoint. The Steeltoe.Management.Endpoint.Actuators.HttpExchanges DEBUG logger also records these URIs, creating a second disclosure channel for users with log access. This issue is fixed in version 4.3.0.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 09/17/2026
The vulnerability identified within the Steeltoe open-source project represents a significant information disclosure flaw affecting cloud-native application management interfaces. Steeltoe provides libraries designed to facilitate the development of applications that operate effectively within cloud environments, often exposing diagnostic and monitoring endpoints for operational oversight. Specifically, the issue resides in the Management.Endpoint component's HttpExchanges actuator endpoint, which is intended to record HTTP request details for debugging and analysis purposes. Prior to version 4.3.0, this endpoint utilized a MaskedUri mechanism that was designed to sanitize sensitive user information embedded within URI paths or fragments, such as usernames or passwords in basic authentication headers. However, the implementation failed to extend this sanitization logic to query strings appended to URIs. This architectural oversight creates a critical gap where sensitive data transmitted via URL parameters remains visible and unmasked, exposing developers and operators to potential security risks when these endpoints are accessible.
The technical root cause of this vulnerability lies in the incomplete parsing and filtering logic applied to incoming HTTP requests before they are stored or displayed by the HttpExchangeRequest response object. When an application receives a request containing sensitive data within its query string parameters, such as OAuth access tokens, password-reset codes, signed URL signatures, or API keys, these values were passed through without inspection if the IncludeQueryString configuration option was enabled. This setting is often used during development to provide detailed insights into traffic patterns and payload structures. Consequently, any client with network-level access to the exposed management endpoint could retrieve historical request data containing these secrets in plaintext. The vulnerability effectively transforms a debugging tool intended for internal use into an unauthorized information leak channel, as query string parameters are frequently utilized by modern web applications and APIs to pass authentication credentials or session identifiers due to their ease of handling in HTTP standards.
The operational impact of this flaw is severe, particularly in production environments where management endpoints might be inadvertently exposed to broader network segments or where log aggregation systems retain historical data indefinitely. An attacker with access to the HttpExchanges endpoint could harvest valid OAuth tokens and API keys, leading to full account compromise, unauthorized data access, or further lateral movement within the infrastructure. Furthermore, the vulnerability extends beyond just the HTTP response payload; it also affects internal logging mechanisms. The Steeltoe.Management.Endpoint.Actuators.HttpExchanges DEBUG logger records these unsanitized URIs as well. This creates a secondary disclosure vector for any user or process with read access to application logs. In many enterprise environments, log files are centralized in systems that may have less stringent access controls than the primary application servers, thereby increasing the blast radius of this information leak. The combination of an exposed API endpoint and verbose logging ensures that sensitive credentials can be extracted through multiple independent channels if proper configuration boundaries are not enforced.
Mitigation strategies for this vulnerability primarily involve upgrading to Steeltoe version 4.3.0 or later, where the masking logic has been corrected to inspect and sanitize query string parameters alongside other URI components. For organizations unable to immediately patch their systems due to compatibility constraints, several compensating controls should be implemented. First, management endpoints such as HttpExchanges must never be exposed in production environments; they are strictly intended for development and debugging phases. Access control lists or network segmentation rules should restrict access to these actuator paths to trusted internal IP addresses only. Additionally, the IncludeQueryString configuration parameter should remain disabled unless absolutely necessary for troubleshooting specific issues, and even then, it should be enabled temporarily and with strict monitoring. Organizations must also review their logging configurations to ensure that sensitive data is not written to log files at any level of verbosity, adhering to the principle of least privilege regarding information retention.
From a classification perspective, this vulnerability aligns with CWE-209, which describes the generation of an error message that includes sensitive information, and more accurately CWE-532, which covers exposure of critical system information for debugging purposes. The attack vector is consistent with ATT&CK technique T1504, specifically Web Session Hijacking or Credential Access via Log Files, depending on whether the attacker exploits the API endpoint directly or accesses stored logs. By addressing this flaw through software updates and rigorous configuration management, organizations can prevent the accidental exposure of high-value credentials embedded in web traffic, thereby maintaining the confidentiality and integrity of their cloud-native applications.