CVE-2026-110924 in Red Hat
Summary
by MITRE • 10/15/2026
A flaw was found in OpenSSH. With GSSAPI authentication enabled, a failed GSSAPI attempt can leave delegated credentials stored for the connection even though user authorization did not succeed. A later successful login on that connection is not authorized by the leftover state.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 10/15/2026
The vulnerability identified within OpenSSH represents a critical flaw in the handling of Generic Security Services Application Program Interface (GSSAPI) authentication, specifically concerning the lifecycle management of delegated credentials during failed authorization attempts. GSSAPI allows for complex authentication mechanisms such as Kerberos, enabling single sign-on capabilities and secure delegation where a client can authenticate to one service using its own identity but then delegate those credentials to access other services on behalf of that user. In this specific scenario, when a GSSAPI authentication attempt fails due to invalid or expired credentials, the OpenSSH server retains the delegated credential context associated with that connection session rather than fully clearing it upon rejection. This behavior deviates from strict security best practices which dictate that any partial state resulting in failure should be purged to prevent potential exploitation through state confusion or reuse.
The operational impact of this flaw stems from the fact that while the initial authentication attempt is rejected, the underlying socket connection remains open and potentially reusable for subsequent interactions within the same session context. If a later request on that same TCP connection attempts to log in using different credentials or a new GSSAPI token, the server may inadvertently reference the leftover state from the previous failed attempt. Although the description notes that the successful login is not authorized by this leftover state, implying that direct privilege escalation via credential reuse might be mitigated by other checks, the presence of residual sensitive security material in memory and connection context poses significant risks. It creates an opportunity for attackers to manipulate session states or potentially exploit race conditions where the timing between a failed GSSAPI attempt and a subsequent authentication request could lead to unexpected behavior, such as information leakage regarding valid credential formats or bypassing certain access controls that rely on clean state transitions.
From a technical perspective, this issue aligns with CWE-20 Improper Input Validation in conjunction with CWE-367 Time-of-check Time-of-use (TOCTOU) race conditions, as the system fails to properly invalidate security context upon authentication failure before allowing further operations on that connection. Furthermore, it relates to ATT&CK technique T1558 Steal or Forge Kerberos Tickets, as GSSAPI is frequently used in conjunction with Kerberos for enterprise authentication. The persistence of delegated credentials after a failed attempt could potentially aid an attacker in crafting more sophisticated attacks against the authentication infrastructure, such as attempting to force re-authentication loops or exploiting implementation-specific quirks in how the SSH daemon handles context cleanup across multiple protocol exchanges on a single persistent connection.
Mitigation strategies for this vulnerability primarily involve updating OpenSSH to versions where the GSSAPI credential handling has been corrected to ensure that any delegated credentials are securely erased from memory and session state immediately upon authentication failure or connection closure. Administrators should also consider implementing strict network segmentation and monitoring of SSH connections, particularly those involving GSSAPI/Kerberos environments, to detect anomalous patterns such as rapid successive failed authentication attempts followed by successful logins on the same IP address within a short timeframe. Additionally, enforcing multi-factor authentication alongside robust password policies can reduce the reliance on single-point credential delegation mechanisms that are susceptible to state-based exploitation vectors. Regular auditing of SSH configuration files to ensure GSSAPI is only enabled where strictly necessary and reviewing logs for unusual authentication sequences will further harden the environment against potential abuse of this flaw.