CVE-2026-91163: Warpgate: Kubernetes listener discloses internal error text to an unauthenticated caller
Warpgate is an open source SSH, HTTPS, and MySQL bastion host for Linux. Prior to 0.29.0, the Kubernetes protocol listener uses AcceptAnyClientCert in warpgate-protocol-kubernetes/src/server/clientcerts.rs to accept certificates at the TLS layer and defer validation to warpgate-protocol-kubernetes/src/server/auth.rs, where authentication and lookup failures are rendered verbatim in an HTTP 500 response body. The Kubernetes application in warpgate-protocol-kubernetes/src/server/mod.rs lacks the outer request-logging wrapper used by the HTTP protocol, and failures in warpgate-protocol-kubernetes/src/server/handlers.rs can short-circuit before its inner log point. An unauthenticated network client can therefore induce failures and receive ASN.1/DER parser diagnostics or seaorm database errors without the attempt being recorded in the gateway log. The disclosed information is limited to internal diagnostics, and no user-data, integrity, or availability impact is established. 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
Who is exposed to this issue?
Warpgate deployments using the Kubernetes protocol listener are exposed if they run a version earlier than 0.29.0 and are reachable by unauthenticated network clients. The issue concerns that listener specifically; the provided information does not establish exposure for the SSH, HTTPS, or MySQL listeners.
What does an attacker need to exploit it?
An attacker needs network access to the Kubernetes listener and does not need credentials or user interaction. They must induce a failure during client-certificate processing, authentication, or lookup, which requires high attack complexity.
What information can be disclosed?
The response may reveal internal ASN.1/DER certificate-parser diagnostics or sea_orm database errors in an HTTP 500 body. The available information states that no user-data disclosure, integrity impact, or availability impact has been established.
How can I tell whether attempts may have occurred?
The affected Kubernetes listener can return these failures before its logging path is reached, so induced failures may not be recorded in the gateway log. Gateway logs alone therefore cannot reliably show whether this issue has been probed or exploited.
What should I do if I cannot immediately upgrade?
Restrict network access to the Kubernetes protocol listener so unauthenticated clients cannot reach it. Upgrade to Warpgate 0.29.0 when possible, as that version fixes the issue.