CVE-2026-91167

Warpgate up to version 0.27.6 has a vulnerability in the browser SSH path where the jump host key is stored for the target address. In Prompt and AutoAccept modes, a machine presenting the jump host key at the target address can be accepted as the target, allowing interception of user traffic and a newly issued certificate when certificate authentication is used. The native SSH path is unaffected because it tracks each hop separately. This issue is fixed in version 0.27.6.

Warpgate is an open source SSH, HTTPS and MySQL bastion host for Linux. Prior to 0.27.6, the response_mode=form_post SSO return path in warpgate-protocol-http/src/api/sso_provider_list.rs uses serde_json::to_string inside ReturnToSsoPostResponse without neutralizing a script-closing sequence. The vulnerable value can enter the script block through the attacker-controlled next redirect parameter stored by warpgate-protocol-http/src/api/sso_provider_detail.rs or through IdP-derived error messages that make_redirect_url concatenates without URL encoding. The IdP-derived path is reachable when the attacker controls a configured identity provider, or when the attacker controls the email or username claim on an attacker-controlled account and the configured identity provider permits the required unvalidated claim format. A victim must complete the form_post SSO flow for the injected markup to be rendered. The Warpgate Content-Security-Policy blocks injected JavaScript and event handlers, so the demonstrated impact is content spoofing, a false login form, or a meta refresh rather than script execution. This issue is fixed in version 0.27.6.

Warpgate up to version 0.27.3 has a vulnerability in HTTP API token authentication where token validation does not enforce the owning user's allowed_ip_ranges against the trusted client address. An attacker holding a leaked, phished, or exfiltrated X-Warpgate-Token can use it from a prohibited network location. Deployments without allowed_ip_ranges are unaffected, and other paths (HTTP target proxying, SSH, MySQL, PostgreSQL, RDP, VNC, Kubernetes) do not accept this vulnerable HTTP token flow. This issue is fixed in version 0.27.3.

Warpgate, an open source SSH, HTTPS and MySQL bastion host for Linux, prior to 0.25.6 has a vulnerability in api_get_recording_stream in warpgate-admin/src/api/recordings_detail.rs. The endpoint /@warpgate/admin/api/recordings/{uuid}/stream is protected only by session authentication, omitting require_admin_permission for AdminPermission::RecordingsView. Any authenticated regular user who identifies an active recording can subscribe to its WebSocket and receive real-time terminal input and output from proxied SSH, MySQL, or PostgreSQL sessions, including credentials and commands.

Warpgate prior to version 0.25.6 has a vulnerability in the HTTP proxy where a client-supplied x-warpgate-username header is forwarded before the authenticated username is appended. Because the request builder preserves repeated values, a proxied backend that trusts the first value can authorize an authenticated attacker as another user. The same forwarding policy also accepts the reserved x-warpgate-authentication-type header. This issue is fixed in version 0.25.6.

Warpgate is an open source SSH, HTTPS and MySQL bastion host for Linux. Prior to 0.25.5, the /@warpgate/api/sso/providers/:name/start endpoint stores an attacker-controlled next parameter that the POST /@warpgate/api/sso/return handler inserts without HTML escaping into the response generated by warpgate-protocol-http/src/api/sso_provider_list.rs. A victim who follows a crafted link and completes SSO can cause markup and JavaScript to execute in the authenticated Warpgate origin, allowing access to session data and actions through user APIs, and through administrator APIs only when the victim is an administrator. The GET /@warpgate/api/sso/return path also uses the same unvalidated value as a redirect destination, enabling an open redirect.

Warpgate is an SSH, HTTPS and MySQL bastion host for Linux that doesn't need special client apps. An attacker may authenticate as another user when logging in as a user with SSO enabled, and any user account without a second factor enabled could be compromised.