Warpgate’s browser SSH implementation incorrectly handles unknown host keys. When a jump host presents an unknown key, the code trusts the key by associating it with the target address rather than the hop identity. As a result, the jump host’s key is stored as if it were the target’s key. An attacker can exploit this by presenting a jump host that supplies a key identical to a legitimate target’s key, causing the system to accept the attacker as the target and enable traffic interception or issuance of new certificates under certificate authentication.

Affected versions are Warpgate v0.25.0 through v0.27.5 inclusive. The fix was deployed in v0.27.6. Only the browser SSH path is impacted; the native SSH path keeps separate hop tracking. The product is the Warpgate SSH, HTTPS, and MySQL bastion host from warp‑tech.

The vulnerability carries a CVSS score of 5.7 and currently has no EPSS value or KEV listing, suggesting that it is not known to be exploited in the wild. Based on the description, it is inferred that an attacker would need to supply a jump host that uses a key matching the target's key, which can be achieved if the attacker can control or spoof a jump host within the user’s network or if there is an internal compromise. The likely attack vector is the ability to act as a jump host or modify a jump host’s key presented to the web SSH client. Due to the lack of publicly available exploits and the moderate severity, the risk is considered moderate, but organizations that rely on Web SSH should patch promptly.