Warpgate EUVD-2026-84062

Exploitation requires two specific conditions to both hold. First, the targeted Warpgate user account must have allowed_ip_ranges configured - the advisory states deployments without allowed_ip_ranges are entirely unaffected. Second, the attacker must already possess a valid X-Warpgate-Token for that user, obtained out-of-band via leak, phishing, or exfiltration (the vulnerability does not mint or forge tokens). The exposure is further limited to the HTTP API token flow reaching endpoints like /@warpgate/api/info and profile data; the description explicitly excludes HTTP target proxying and the SSH, MySQL, PostgreSQL, RDP, VNC, and Kubernetes paths. Affected versions are 0.23.0 through before 0.27.3; upgrading to 0.27.3 (which binds tokens to the user's allowed ranges and honors user lockout) removes the flaw.

This is a genuinely low-priority, tightly-gated access-control weakness - not a high-CVSS-masquerading issue, and the vendor's 4.3 (MEDIUM) rating is honest. The CVSS 3.1 vector CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N is consistent with the description: PR:L reflects that the attacker must already hold a valid API token (a credential), and impact is confidentiality-only and limited (C:L, I:N, A:N) because the vulnerable HTTP token flow only exposes profile/info-level API endpoints. Critically, the flaw is a defense-in-depth bypass rather than a primary auth bypass: the attacker needs a leaked/phished/exfiltrated X-Warpgate-Token AND the deployment must actually configure allowed_ip_ranges (default-off deployments are explicitly unaffected). No EPSS score, no CISA KEV listing, and no public exploit code were provided - the only 'exploit' artifacts are the vendor's own regression tests in PR #2356. No SSVC decision data was supplied. There are no conflicting signals between the vector and description; both agree this requires prior credential compromise plus a specific hardening config, so real-world exploitation is contingent on a separate token-theft event succeeding first.

An operator hardens a Warpgate user account with allowed_ip_ranges so its API tokens should only work from a corporate IP range. An attacker who has separately phished or exfiltrated that user's X-Warpgate-Token (e.g. from a leaked script, CI secret, or compromised endpoint) then replays it from an arbitrary/prohibited network and Warpgate accepts it, reading the victim's profile/info via the HTTP API. No public exploit code exists; only vendor regression tests demonstrate the behavior.