The vulnerability occurs in Warpgate versions 0.23.0 through 0.27.2, where HTTP API token authentication resolves a token into a UserToken without enforcing the owning user's allowed_ip_ranges. This logic flaw allows an attacker with a valid X‑Warpgate‑Token to use the token from any network location, bypassing IP restrictions that should normally limit access to trusted clients. The impact is the ability to access resources protected by the token from unauthorized network locations.

Affected deployments run the open source SSH, HTTPS and MySQL bastion host Warpgate from warp‑tech. The flaw applies only to HTTP API token flows; other protocols, such as SSH, MySQL, PostgreSQL, RDP, VNC and Kubernetes paths, do not accept this vulnerable token route. Deployments that do not configure allowed_ip_ranges are unaffected, and the issue was fixed in version 0.27.3.

The CVSS score is 4.3, indicating a moderate impact, and no EPSS value is available. Because the flaw is only exploitable if an attacker already possesses a token, the risk is contingent on token leakage or exfiltration. The vulnerability is not listed in the CISA KEV catalog, suggesting limited or no active exploitation. Nonetheless, an unauthorized network connection using a compromised token can enable further lateral movement or data access within the bastion host.