CVE-2026-91164 in Warpgate
Summary
by MITRE • 09/21/2026
Warpgate is an open source SSH, HTTPS and MySQL bastion host for Linux. From 0.23.0 until 0.27.3, HTTP API token authentication resolves ConfigProvider::validate_api_token into RequestAuthorization::UserToken without enforcing the owning user's allowed_ip_ranges against the trusted client address in warpgate-protocol-http/src/common.rs. An attacker holding a leaked, phished, or exfiltrated X-Warpgate-Token can therefore use it from a prohibited network location. Deployments without allowed_ip_ranges are unaffected, and HTTP target proxying plus SSH, MySQL, PostgreSQL, RDP, VNC, and Kubernetes paths do not accept this vulnerable HTTP token flow. This issue is fixed in version 0.27.3.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 09/21/2026
The vulnerability identified within Warpgate versions ranging from 0.23.0 to 0.27.3 represents a critical authentication bypass flaw rooted in the improper enforcement of network-based access controls during HTTP API token validation. Warpgate functions as an open-source bastion host designed to secure SSH, HTTPS, and MySQL connections for Linux environments by acting as a centralized gateway that enforces strict security policies before granting access to backend resources. The core issue resides within the authentication logic located in the warpgate-protocol-http/src/common.rs module, specifically during the resolution of ConfigProvider::validate_api_token into RequestAuthorization::UserToken. When an HTTP API token is presented for authentication, the system correctly identifies the user associated with that token but fails to cross-reference the client's source IP address against the configured allowed_ip_ranges policy defined in the Warpgate configuration file. This omission means that while the identity of the attacker may be verified through a valid or stolen token, the geographical and network-based restrictions intended to limit where that identity can operate are completely ignored during this specific authentication flow.
This technical flaw allows an adversary who possesses a leaked, phished, or exfiltrated X-Warpgate-Token to authenticate from any IP address, regardless of whether that location is explicitly prohibited by the organization's security policies. In typical bastion host deployments, allowed_ip_ranges serve as a vital layer of defense-in-depth, ensuring that even if credentials are compromised, they cannot be used outside of trusted networks such as internal corporate LANs or specific VPN subnets. By bypassing this check, an attacker gains unrestricted access to the Warpgate interface from remote locations, potentially facilitating lateral movement within the network or unauthorized access to sensitive backend services depending on how the bastion host is integrated into the broader infrastructure architecture. The impact is particularly severe in environments where strict compliance with regulatory standards requires proof of origin for administrative actions, as this vulnerability effectively nullifies one of the primary mechanisms used to enforce such controls.
It is important to note that the scope of this vulnerability is limited to specific authentication paths and does not affect all connection types supported by Warpgate. Deployments that have not configured allowed_ip_ranges are inherently unaffected because there are no network restrictions to bypass, rendering the flaw moot in those configurations. Furthermore, the HTTP token flow described here is exclusive to certain administrative or API interactions; it does not apply to direct target proxying for SSH, MySQL, PostgreSQL, RDP, VNC, and Kubernetes connections. These other protocols utilize different authentication mechanisms that do suffer from proper IP validation checks, thereby limiting the attack surface primarily to scenarios where an attacker interacts with the HTTP-based management interface using a stolen API token rather than attempting to tunnel through standard service ports.
From a classification perspective, this vulnerability aligns closely with CWE-284 Improper Access Control and CWE-306 Missing Authentication for Critical Function in contexts where network restrictions are part of the access control policy. In terms of adversary behavior as mapped by MITRE ATT&CK, this flaw facilitates Initial Access via Valid Accounts combined with Lateral Movement if the bastion host is used to pivot into restricted zones, although the primary failure here is a violation of security architecture principles regarding location-based trust boundaries. To mitigate this risk, organizations running Warpgate versions between 0.23.0 and 0.27.3 must immediately upgrade to version 0.27.3 or later where the validation logic has been corrected to enforce allowed_ip_ranges during HTTP API token authentication. Additionally, until an upgrade is performed, administrators should rotate all existing X-Warpgate-Tokens to invalidate any potentially compromised credentials and ensure that no sensitive operations are conducted via the vulnerable HTTP endpoint from untrusted networks if possible.