GPU VulnDB

Database/Container, Kubernetes & orchestration

Warpgate: Kubernetes correlation entries keyed by username survive account deletion, bypassing target authorization

CVSS 6.8CVE-2026-91168Container, Kubernetes & orchestrationcurated

Impact

Warpgate's Kubernetes correlator keys an authorized AdmittedTarget by username, target name and client IP instead of the user's immutable UUID, and closing a session does not evict the entry. Delete an account and create a different, low-privilege account with the same username, and the replacement can authenticate and reuse the predecessor's live correlation entry when it asks for the same target from the same client IP before kubernetes.session_max_age expires. Authentication of the current request still happens, but the fresh target authorization check is skipped, so Warpgate proxies the request with Kubernetes credentials the new account was never granted - read access to cluster resources, or mutations, on whatever cluster that target fronts. For an operator using Warpgate as the bastion in front of a GPU cluster's API server, username recycling is enough to hand someone else's cluster rights to a new hire.

Who can reach it

Network attacker who holds valid credentials for a newly created low-privilege Warpgate account whose username matches a deleted one, and who connects from the same client IP within the session window. Authentication is required.

What to do

Upgrade Warpgate to 0.29.0 (commit 2f77f07b8335) and restart the service - a daemon restart, no node reboot. If you cannot upgrade immediately, stop reusing usernames for new accounts, lower kubernetes.session_max_age, and restart Warpgate after deleting any account that had Kubernetes targets so stale entries are dropped.

References

Related entries

All Container, Kubernetes & orchestration entries

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.