CVE-2026-91164: Warpgate Authentication Bypass Vulnerability

CVE-2026-91164 Overview

Warpgate is an open source SSH, HTTPS, and MySQL bastion host for Linux. CVE-2026-91164 is a broken access control vulnerability [CWE-284] affecting Warpgate versions 0.23.0 through 0.27.2. The HTTP API token authentication path in warpgate-protocol-http/src/common.rs fails to enforce the owning user's allowed_ip_ranges setting against the trusted client address. An attacker who obtains a valid X-Warpgate-Token through leakage, phishing, or exfiltration can reuse it from network locations that administrators explicitly prohibited. The issue is fixed in version 0.27.3.

Critical Impact
Leaked HTTP API tokens can be replayed from unauthorized network locations, bypassing the network segmentation controls configured via allowed_ip_ranges.

Affected Products

Warpgate versions 0.23.0 through 0.27.2
Deployments that configure allowed_ip_ranges on user accounts
HTTP API token authentication flow (X-Warpgate-Token)

Discovery Timeline

2026-09-21 - CVE-2026-91164 published to NVD
2026-09-24 - Last updated in NVD database

Technical Details for CVE-2026-91164

Vulnerability Analysis

Warpgate enforces per-user network restrictions through the allowed_ip_ranges configuration option. This control is intended to bind an account's usage to specific source networks regardless of credential type. The vulnerability breaks that assumption for HTTP API tokens only. Other protocol paths, including HTTP target proxying and SSH, MySQL, PostgreSQL, RDP, VNC, and Kubernetes flows, correctly enforce the restriction.

Deployments that never configure allowed_ip_ranges are unaffected, because there is no source-network policy to bypass. Where the setting is used as a compensating control against credential theft, however, the protection does not apply to HTTP API tokens.

Root Cause

Inside ConfigProvider::validate_api_token, a successful token match resolves to a RequestAuthorization::UserToken result without invoking the shared IP allowlist check. The check_ip_allowed helper in warpgate-core/src/auth_state_store.rs is defined but was not called on this code path. As a result, token validation returned success even when the client's remote address fell outside the configured ranges.

Attack Vector

Exploitation requires an attacker to possess a valid X-Warpgate-Token. Tokens can be obtained through phishing, log exposure, backup exfiltration, or endpoint compromise. Once obtained, the attacker issues HTTP API requests to the Warpgate instance from any network reachable to the service. The pre-patch server accepts the request even when the source IP violates the token owner's allowed_ip_ranges policy.

The upstream patch adds IP allowlist validation to the HTTP token path and tightens visibility on the helper function:

rust

 use std::fmt::Debug;
-use std::net::ToSocketAddrs;
+use std::net::{IpAddr, ToSocketAddrs};
 
 use poem::http::{Method, StatusCode, Uri};
 use poem::web::RemoteAddr;

rust

 /// Checks whether the given IP is allowed by the user's `allowed_ip_ranges` setting.
 /// Returns `Ok(())` if access is allowed, or an appropriate `WarpgateError` if denied.
-pub fn check_ip_allowed(
+pub(crate) fn check_ip_allowed(
     allowed_ip_ranges: Option<&Vec<WarpgateIpNet>>,
     remote_ip: Option<IpAddr>,
     username: &str,

Source: GitHub Commit 8cb33a1

Detection Methods for CVE-2026-91164

Indicators of Compromise

HTTP requests carrying X-Warpgate-Token headers from source IPs outside a user's documented allowed_ip_ranges.
Successful API authentications for a user account originating from geographies or ASNs inconsistent with historical baselines.
Concurrent token usage from disparate source addresses within short time windows.

Detection Strategies

Compare Warpgate HTTP access logs against the effective allowed_ip_ranges configuration for each user and alert on mismatches.
Correlate X-Warpgate-Token authentications with the user's SSH, RDP, and other protocol session sources to identify divergent client IPs.
Track token-authenticated request volume per source IP and flag first-seen or low-reputation addresses.

Monitoring Recommendations

Forward Warpgate audit logs to a centralized analytics platform and retain client IP, user, and authentication method fields.
Baseline expected API client networks per service account and alert on deviations.
Monitor upgrades of the Warpgate binary to confirm all instances run 0.27.3 or later.

How to Mitigate CVE-2026-91164

Immediate Actions Required

Upgrade Warpgate to version 0.27.3 or later on all bastion hosts.
Rotate every issued HTTP API token, since existing tokens may have been used from unauthorized locations.
Review recent HTTP API access logs for token usage from IPs outside configured allowed_ip_ranges.

Patch Information

The fix is shipped in Warpgate 0.27.3. See GitHub Release v0.27.3, the fix commit in GitHub Commit 8cb33a1, and the coordinating GitHub Pull Request #2356. The advisory is published as GHSA-qmr2-wp96-h9ff.

Workarounds

Disable HTTP API token authentication until the upgrade is complete, forcing interactive login through protocol paths that enforce allowed_ip_ranges.
Restrict network reachability to the Warpgate HTTP listener using an upstream firewall or load balancer that enforces source IP allowlists.
Reduce token lifetimes and revoke unused tokens to shrink the window in which a leaked token remains valid.

bash

# Verify installed Warpgate version and upgrade
warpgate --version

# Example: pull and run the patched release
docker pull ghcr.io/warp-tech/warpgate:0.27.3
systemctl restart warpgate

# Revoke all existing HTTP API tokens via the admin CLI, then reissue as needed
warpgate admin tokens list
warpgate admin tokens revoke --all