Description

Warpgate is an open source SSH, HTTPS and MySQL bastion host for Linux. Prior to 0.25.6, copy_server_request in warpgate-protocol-http/src/proxy.rs forwards a client-supplied x-warpgate-username header before inject_own_headers appends the authenticated username. Because the request builder preserves repeated values, a proxied backend that trusts the first x-warpgate-username value can authorize an authenticated attacker as another user. The same forwarding policy also accepts the reserved x-warpgate-authentication-type header, and warpgate-common/src/http_headers.rs does not exclude either reserved identity header. This issue is fixed in version 0.25.6.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "4.9",
  "pubDate": "2026-09-21T19:17:08.290Z",
  "pubdate": "2026-09-21T19:17:08.290Z",
  "executiveSummary": "Warpgate versions prior to 0.25.6 contain a critical vulnerability involving the improper handling of HTTP headers during request proxying. The issue stems from the application forwarding client-supplied identity headers—specifically 'x-warpgate-username' and 'x-warpgate-authentication-type'—to backend services before injecting the authenticated identity.\nBecause the proxy preserves multiple instances of these headers, a malicious authenticated user can manipulate the request to spoof their identity to the backend service. If the downstream application is configured to trust the first instance of a header, an attacker can masquerade as a different user, potentially gaining unauthorized access or elevated privileges.\nThis vulnerability represents a significant risk to access control policies enforced at the application level behind the Warpgate bastion host. Exploitation requires the attacker to be authenticated to the Warpgate instance, but does not require administrative privileges. The vulnerability is remediated in version 0.25.6, which updates the header handling logic to properly sanitize reserved identity headers before forwarding requests to backend infrastructure.",
  "technicalDetails": "The vulnerability resides in the request proxying logic defined in 'warpgate-protocol-http/src/proxy.rs', specifically within the 'copy_server_request' function. During the processing of an incoming HTTP request, Warpgate prepares the request for forwarding to the target backend. The current implementation forwards client-supplied headers, including sensitive reserved headers like 'x-warpgate-username', before the 'inject_own_headers' function appends the validated, server-authoritative identity headers.\nThe root cause is a failure to strip or overwrite reserved identity headers provided by the client. Since the HTTP request builder used by Warpgate preserves repeated header values, the final proxied request contains both the client-provided header and the server-injected header. Many backend web servers or middleware components default to reading the first occurrence of a header in a sequence. Consequently, if a malicious user provides a custom 'x-warpgate-username' header in their initial request, the backend will receive that user-supplied string before the legitimate one.\nThe attack flow proceeds as follows: 1) An authenticated user initiates a request through Warpgate to a proxied backend. 2) The user injects a malicious 'x-warpgate-username' header into the request. 3) Warpgate's 'copy_server_request' function copies this header into the outgoing request buffer. 4) The 'inject_own_headers' function appends the legitimate identity header. 5) The backend receives a request containing multiple 'x-warpgate-username' entries. 6) The backend processes the first entry (the attacker's choice) for authorization logic, effectively resulting in identity spoofing.\nAdditionally, 'warpgate-common/src/http_headers.rs' fails to explicitly exclude the reserved 'x-warpgate-authentication-type' header from being forwarded. This allows an attacker to manipulate the reported authentication context, which may further influence downstream authorization decisions. This vulnerability affects all Warpgate deployments prior to version 0.25.6. The exploitation is restricted to authenticated users but facilitates lateral movement or privilege escalation within the context of the internal network protected by the bastion. The lack of input sanitization in the proxy layer allows users to override security-critical metadata that backend services rely on for trusted identity propagation."
}