CVE-2026-91166: Warpgate: Web SSH stores a jump host's key against the target's address, so it validates as the target
Warpgate is an open source SSH, HTTPS and MySQL bastion host for Linux. From 0.25.0 until 0.27.6, the browser SSH path in warpgate-web-ssh/src/manager.rs handles RCEvent::HostKeyUnknown without the presenting hop identity and instead passes sshoptions.host and sshoptions.port for the final target to KnownHosts::trust. In Prompt and AutoAccept modes, a jump host key can therefore be stored for the target address. A machine later presenting the jump host key at the target address can be accepted as the target, allowing interception of user traffic and a newly issued certificate when certificate authentication is used. The native SSH path is unaffected because it tracks each hop separately. This issue is fixed in version 0.27.6.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
warpgate-web-sshto a version that resolves this vulnerability.Fixed in 0.27.6 - Compensating control
If Prompt or AutoAccept modes were used, re-issue/re-verify any host key entries that may have been stored for the target address from a jump host (to prevent future validation/interception risks) until the system is upgraded to warpgate version 0.27.6.
Event History
Frequently Asked Questions
Which deployments are affected?
Warpgate versions from 0.25.0 through 0.27.6 are affected in the browser-based SSH path. The native SSH path is unaffected because it tracks each hop separately.
What conditions are required for exploitation?
The browser SSH connection must use a jump host, and host-key handling must be in Prompt or AutoAccept mode. An attacker must be able to present the jump host's key at the final target address after that key has been stored against the target.
What is the practical impact if exploitation succeeds?
A machine presenting the jump host key at the target address can be accepted as the target, enabling interception of user traffic. If certificate authentication is used, the attacker can also receive a newly issued certificate.
How should this be remediated?
Update Warpgate to version 0.27.6, which fixes the issue.