CVE-2026-58491

In Warpgate prior to version 0.28.4, the PUT /@warpgate/admin/api/users/:id/roles/:role_id endpoint does not require AdminPermission::AccessRolesAssign. A limited administrator with any permission can update expires_at on an existing UserRoleAssignment and clear revoked_at, extending an expiring grant or reinstating a revoked grant.

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 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.