CVE-2026-91168: Warpgate: Kubernetes authorization correlation can be reused by a recreated same-name account
Warpgate is an open source SSH, HTTPS, and MySQL bastion host for Linux. From 0.21.0 until 0.29.0, the Kubernetes request correlator in warpgate-protocol-kubernetes/src/correlator.rs keys an authorized AdmittedTarget by username, targetname, and client IP rather than by the immutable user UUID, while KubernetesSessionHandle::close does not evict the entry. If an account is deleted and a different low-privilege account is created with the same username, the replacement account can successfully authenticate as that recreated username and reuse the predecessor's still-live correlation entry when requesting the same target from the same client IP before kubernetes.sessionmaxage expires. Current-request authentication still occurs, but the reused entry bypasses a fresh target authorization check and can cause Warpgate to proxy requests with Kubernetes target credentials that the replacement account is not authorized to use, exposing cluster resources or permitting unauthorized mutations. This issue is fixed in version 0.29.0.
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
warpgateto a version that resolves this vulnerability.Fixed in 0.29.0
Event History
Frequently Asked Questions
Which deployments are exposed?
Warpgate deployments running versions from 0.21.0 through versions before 0.29.0 are affected where Kubernetes access is used. Exploitation requires an authorized correlation entry to remain live for the same username, target, and client IP.
What must an attacker be able to do to exploit this issue?
The predecessor account must be deleted and replaced by a different low-privilege account with the same username. That replacement account must authenticate successfully, use the same target and client IP, and act before kubernetes.session_max_age expires.
Does the replacement account bypass authentication entirely?
No. Warpgate still authenticates the current request. The flaw reuses a live correlation entry and bypasses a new target authorization check, potentially causing requests to use Kubernetes target credentials the replacement account is not authorized to use.
How can this be remediated?
Upgrade Warpgate to version 0.29.0, which fixes the issue.