Description

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 ssh_options.host and ssh_options.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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "5.7",
  "pubDate": "2026-09-21T19:17:15.383Z",
  "pubdate": "2026-09-21T19:17:15.383Z",
  "executiveSummary": "A vulnerability exists in the browser-based SSH implementation of Warpgate, affecting versions 0.25.0 through 0.27.6, where the application incorrectly manages host key verification during multi-hop SSH connections.\nThe flaw stems from an improper handling of the 'RCEvent::HostKeyUnknown' event, which leads to the conflation of jump host keys with the final target host identity.\nIn configurations utilizing 'Prompt' or 'AutoAccept' modes, this architectural oversight allows a malicious jump host to present its own public key for the destination address, resulting in the persistence of this fraudulent key in the 'KnownHosts' store.\nAn attacker can exploit this condition to intercept encrypted SSH traffic or perform man-in-the-middle (MITM) attacks. By successfully impersonating the target, the attacker can influence certificate issuance when certificate-based authentication is enabled.\nThe vulnerability is restricted to the web-based SSH path; the native SSH client remains unaffected as it maintains distinct identity tracking for each hop in the connection chain.\nThis represents a high-risk security flaw as it facilitates transparent credential and traffic interception without triggering standard host key mismatch alerts.",
  "technicalDetails": "The vulnerability originates in 'warpgate-web-ssh/src/manager.rs', specifically within the logic governing the 'RCEvent::HostKeyUnknown' event handler. When a user initiates a browser-based SSH session through a bastion host, the system fails to correctly associate the host key with the specific hop being traversed.\nInstead of validating the identity of the current hop, the application erroneously utilizes 'ssh_options.host' and 'ssh_options.port'—variables reserved for the final destination server—to verify and register the host key via the 'KnownHosts::trust' function. This logic error effectively binds the jump host's public key to the destination address within the local 'KnownHosts' storage mechanism.\nThe exploitation flow proceeds as follows: First, an attacker controls or intercepts traffic from an intermediate jump host. Second, when a victim initiates a browser-based SSH connection, the Warpgate web interface triggers an 'RCEvent::HostKeyUnknown' event. Third, due to the flawed implementation, the browser-SSH manager trusts the key provided by the jump host as if it were the authentic key for the final destination. Finally, the malicious key is persisted in the trust store.\nOnce the jump host key is stored as the valid key for the final destination, any subsequent connection attempt by the user to that target will automatically trust the attacker's key. This facilitates a seamless man-in-the-middle position where the attacker can inspect, modify, or intercept traffic intended for the final host. Furthermore, because the attacker is now the 'trusted' endpoint, they can manipulate the handshake process to intercept or influence the issuance of newly generated certificates in scenarios where certificate authentication is utilized.\nThe scope of this vulnerability is limited to versions 0.25.0 to 0.27.6 and is exclusive to the web-SSH component, as the native SSH path architecture correctly isolates the verification state for individual hops. Exploitation requires no prior authentication to the target, though it necessitates that the victim utilize the 'Prompt' or 'AutoAccept' modes of host key management, which are common configurations for ease of use in bastion host environments."
}