Warpgate EUVD-2026-84064

Exploitation requires a specific chain of conditions, all of which limit real-world risk: (1) the victim must use Warpgate's browser/web SSH path (warpgate-web-ssh), not the native SSH proxy, which tracks each hop separately and is unaffected; (2) the accessed target must be reached through an SSH jump/proxy host so that a jump-host key is presented during connection; (3) the host-key verification mode must be Prompt or AutoAccept (so the jump key is stored under the target address - in Prompt mode a user must actively accept the key, matching UI:R); (4) the attacker must control the jump host or otherwise possess its private key in order to complete the SSH handshake when re-presenting that key; and (5) the attacker must hold a man-in-the-middle position at the target address. Impact is greatest when certificate authentication is used, since a new certificate is issued to the impersonating machine. Only versions 0.25.0 through before 0.27.6 are affected; upgrade to 0.27.6 removes the vulnerable web-SSH trust logic.

This is a genuine but high-barrier trust-confusion flaw, not a mass-exploitation priority. The vendor CVSS 3.1 vector (AV:N/AC:H/PR:H/UI:R/S:U/C:H/I:H/A:N, 5.7 Medium) already encodes multiple limiting gates: high attack complexity, high privileges, and required user interaction. No EPSS score, no CISA KEV listing, and no public POC are present in the intelligence - consistent with a subtle host-key-handling bug in a niche open-source bastion rather than a widely targeted vulnerability. The real risk is bounded by the exploitation preconditions rather than the network attack vector: the attacker must effectively control (hold the private key of) the SSH jump/proxy host, hold a network man-in-the-middle position at the target address, and rely on a target configured with a jump host in Prompt or AutoAccept host-key mode. One caveat on the metadata: the sole impact-oriented tag is 'Information Disclosure', which captures only the confidentiality (traffic interception) facet - the underlying weakness (CWE-297, host key/certificate host mismatch) is a spoofing/MITM issue that also has integrity impact (I:H, malicious acceptance as the target and issuance of a new certificate under cert auth). PR:H is defensible as a proxy for 'must control the jump host' but is debatable in strict CVSS terms because the attacker holds no privileges on the Warpgate component itself. Treat as a patch-in-normal-cycle item, prioritized higher only for deployments using browser SSH with jump hosts and certificate authentication.

An operator uses Warpgate's browser (web) SSH to reach a target that is reached via an SSH jump host, in Prompt or AutoAccept host-key mode; Warpgate incorrectly stores the jump host's key under the target's address. An attacker who controls the jump host and can intercept traffic to the target later presents that same key at the target address, is accepted as the target, and intercepts the user's session - obtaining a freshly issued certificate when certificate authentication is in use. No public exploit code was identified at the time of analysis, and the high complexity plus required jump-host control make this an opportunistic-to-targeted scenario rather than a turnkey attack.