CVE-2026-91166: Warpgate SSH Bastion Information Disclosure

CVE-2026-91166 Overview

Warpgate is an open source SSH, HTTPS, and MySQL bastion host for Linux. A host key confusion flaw in the browser SSH path affects versions 0.25.0 through 0.27.5. The warpgate-web-ssh/src/manager.rs component handles RCEvent::HostKeyUnknown without carrying the presenting hop identity. Instead, it 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 be stored against the target address. An attacker later presenting the jump host key at the target address can be trusted as the target, intercepting user traffic and any newly issued certificate when certificate authentication is used.

Critical Impact
Attackers controlling a jump host can impersonate downstream targets, intercept SSH sessions, and capture freshly issued client certificates.

Affected Products

Warpgate 0.25.0 through 0.27.5 (browser SSH path)
warpgate-web-ssh component
Deployments using Prompt or AutoAccept host key modes

Discovery Timeline

2026-09-21 - CVE-2026-91166 published to the National Vulnerability Database (NVD)
2026-09-24 - Last updated in NVD database
Version 0.27.6 - warp-tech releases patched Warpgate build

Technical Details for CVE-2026-91166

Vulnerability Analysis

The flaw is an improper certificate/host key validation weakness classified under [CWE-297]. Warpgate proxies SSH connections through optional jump (hop) hosts before reaching a final target. In the native SSH path, each hop tracks its host key separately. The browser SSH path collapses this distinction by using only the final target's host and port as the storage key for trusted host keys.

When RCEvent::HostKeyUnknown fires during a hop handshake, the browser code presents the jump host's public key to the operator but records acceptance under the target's address. Once accepted, any server later presenting that key at the target endpoint passes trust checks, enabling a machine-in-the-middle position against downstream SSH sessions.

Root Cause

The HostKeyUnknown event lacked contextual identity for which hop was actually presenting the key. The trust store keyed entries solely on ssh_options.host and ssh_options.port of the terminal target, so hop keys were persisted under target coordinates. This is a classic identity binding failure between what is displayed to the user and what is recorded in the known-hosts database.

Attack Vector

An attacker who operates or compromises a jump host used by Warpgate can wait for a user to accept its host key during the initial connection. That key becomes trusted for the target address. When the same attacker later presents the key at the target endpoint, Warpgate treats the session as authentic. If certificate-based user authentication is in use, the attacker can capture the freshly issued client certificate and reuse it against the real target.

rust

// Patch: warpgate-protocol-ssh/src/client/mod.rs
// The HostKeyUnknown event now carries the presenting hop's host and port
// so trust decisions bind to the correct identity.
     Done,
     HostKeyReceived(PublicKey),
-    HostKeyUnknown(PublicKey, oneshot::Sender<bool>),
+    HostKeyUnknown(PublicKey, String, u16, oneshot::Sender<bool>),
     ForwardedTcpIp(Uuid, ForwardedTcpIpParams),
     ForwardedStreamlocal(Uuid, ForwardedStreamlocalParams),
     ForwardedAgent(Uuid),

Source: warp-tech/warpgate commit fb66ff7

Detection Methods for CVE-2026-91166

Indicators of Compromise

Entries in the Warpgate known-hosts store that map a jump host's public key to a downstream target's host and port.
Repeated HostKeyUnknown prompts for the same target followed by successful acceptance in browser SSH sessions.
Unexpected reissuance of client certificates immediately after a browser SSH session against a proxied target.

Detection Strategies

Audit the Warpgate host key database for duplicate public keys associated with distinct hop and target addresses.
Compare host keys recorded by the browser SSH path against those seen by the native SSH path for the same targets.
Alert on Warpgate deployments still running versions between 0.25.0 and 0.27.5 in AutoAccept mode.

Monitoring Recommendations

Forward Warpgate audit logs and SSH session records to a centralized analytics platform for correlation and long-term retention.
Monitor jump host infrastructure for unauthorized access, configuration changes, or unexpected key rotations.
Track issuance events from any SSH certificate authority integrated with Warpgate for anomalous frequency or endpoints.

How to Mitigate CVE-2026-91166

Immediate Actions Required

Upgrade Warpgate to version 0.27.6 or later on all bastion hosts.
Purge existing known-hosts entries created via the browser SSH path and reverify target host keys out of band.
Restrict use of AutoAccept host key mode and require explicit review of new key prompts.

Patch Information

The fix landed in Warpgate 0.27.6. The patch extends RCEvent::HostKeyUnknown to carry the presenting hop's host string and port, so KnownHosts::trust binds entries to the correct identity. See Warpgate release v0.27.6 and GHSA-w9jj-vpw3-5r8f.

Workarounds

Use the native SSH client path, which tracks each hop's host key independently and is not affected.
Disable jump host configurations in the browser SSH path until upgrading to 0.27.6.
Enforce strict prompt-based confirmation and out-of-band host key verification for all new target connections.

bash

# Verify installed Warpgate version and upgrade
warpgate --version
# Fetch and install v0.27.6 from the official release page
# https://github.com/warp-tech/warpgate/releases/tag/v0.27.6