CVE-2026-91168 · Package
NO FIX YET · SEE WHAT TO DO
Warpgate, a bastion host for SSH, HTTPS and MySQL, caches Kubernetes target authorization by username rather than user ID, and does not clear the cache when a session closes. A new low-privilege account created with a deleted account's username can reuse that cached entry and reach Kubernetes cluster resources with the old account's target credentials.
first public Sep 18, 2026 · 1 source
Is this in your stack? Find out in 2 minutes.
Tell InfraStack what you run. It checks this one, and every next one, against your stack.
Ask from here. InfraStack checks the affected versions against your stack and answers in your inbox.
InfraStack checks the affected versions against your stack and answers in Slack, with the evidence and the fix.
Teams running Warpgate 0.21.0 through 0.28.x that use its Kubernetes target support and can delete and recreate user accounts. The flaw needs the replacement account to authenticate successfully and connect from the same client IP within the session max age window. Deployments without Kubernetes targets, or that never reuse usernames, are less exposed.
Not affected if no-kubernetes-targets, version-0.29.0-or-later
Who cares kubernetes, self-hosted, warpgate
warpgate --version; versions from 0.21.0 through 0.28.x are in the affected range.0.29.0.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, target_name, 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.session_max_age 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.
This page as .md · .json · in your agent: get_signal("CVE-2026-91168") · CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:N
NVD data is provided by NIST and is public domain. Posts quoted belong to their authors.