Warpgate EUVD-2026-84060

Requires two prerequisites: (1) the attacker holds a valid authenticated Warpgate session (PR:L), and (2) a backend proxied through Warpgate that trusts the reserved x-warpgate-username (or x-warpgate-authentication-type) identity header AND resolves duplicate/repeated headers by taking the FIRST value - Warpgate forwards the client-supplied value ahead of its own injected authenticated username. Limiting factors: no impact against backends that read the last header value, deduplicate reserved headers, or ignore these headers; only Warpgate versions prior to 0.25.6 are affected (0.25.6 adds may_forward_header() which strips any x-warpgate- prefixed and DONT_FORWARD headers). This is the AC:H condition - success depends on downstream header-parsing semantics outside the attacker's direct control.

This is a genuine but conditional access-control weakness, not a drive-by critical. The CVSS 3.1 vector (AV:N/AC:H/PR:L/UI:N/S:C/C:L/I:L/A:N = 4.9 Medium) aligns well with the mechanism: exploitation is network-borne but requires an already-authenticated Warpgate account (PR:L) AND a specific backend condition - the proxied backend must trust the FIRST of two repeated x-warpgate-username header values (AC:H). No EPSS score, no CISA KEV listing, and no public POC are present in the input, so all three exploitation-likelihood signals are absent rather than elevated. The scope change (S:C) is justified: the flaw in the Warpgate proxy causes an identity decision to be corrupted in a separate downstream backend. Impacts are limited (C:L/I:L/A:N) because the attacker gains another user's identity context rather than full data compromise or code execution. Net: real, defensible medium-severity identity-spoofing/broken-access-control issue that is meaningfully gated by backend trust behavior; not a widespread-exploitation priority absent evidence.

An attacker with a valid low-privilege Warpgate account sends an HTTP request through the bastion carrying a forged x-warpgate-username (and/or x-warpgate-authentication-type) header. Because Warpgate forwards the client-supplied value before appending the real authenticated username, a backend that reads the first x-warpgate-username value authorizes the request as the impersonated user. No public exploit code is identified at time of analysis; exploitation depends on the downstream app's header-parsing behavior.