CVE-2026-110924: 
OpenSSH vulnerability analysis and mitigation

CVE-2026-110924 is an incomplete cleanup vulnerability in OpenSSH affecting systems with GSSAPI authentication enabled. When a GSSAPI authentication attempt fails, delegated credentials can remain stored for the connection even though user authorization did not succeed; a subsequent successful login on the same connection is not properly authorized by the leftover credential state. The flaw was reported by Moritz Theile, disclosed on October 15, 2026, and affects OpenSSH as shipped in Red Hat Enterprise Linux and Red Hat OpenShift (RHEL CoreOS 8 and 9). It carries a CVSS v3.1 base score of 4.8 (Medium) (Red Hat CVE, GitHub Advisory).

The root cause is classified as CWE-459 (Incomplete Cleanup): the ssh_gssapi_storecreds function stores delegated GSSAPI credentials even when ssh_gssapi_userok has not returned success, leaving a gssapi_client structure — including an exported name and credential — populated for the lifetime of the SSH connection. On RHEL 10, GSSAPIDelegateCredentials defaults to yes, and storecreds only returns early when that option is explicitly disabled, making the exposure more likely in default configurations. A subsequent authentication attempt on the same connection can interact with this leftover state, though Red Hat's analysis confirms the leftover credential does not directly authorize the later login (Red Hat CVE, Red Hat Bugzilla). The attack vector is network-based with high complexity and requires no privileges or user interaction.

Successful exploitation results in limited confidentiality and integrity impact: an unauthenticated network attacker who can perform a failed GSSAPI exchange followed by a successful login on the same connection may gain access to delegated Kerberos credentials that were not intended to be stored, potentially enabling unauthorized access to resources the delegated credential grants. Availability is not impacted. The scope is unchanged, meaning the impact is confined to the SSH server component itself, though delegated credentials could theoretically be used for lateral movement within a Kerberos-enabled environment (Red Hat CVE, Red Hat Bugzilla).

As of the disclosure date, there is no public proof-of-concept exploit and no evidence of in-the-wild exploitation (Red Hat CVE). The EPSS score is 0.0, reflecting very low probability of near-term exploitation, and the vulnerability is not listed in the CISA Known Exploited Vulnerabilities catalog. Exploitation requires high attack complexity — specifically, the ability to initiate a GSSAPI exchange on the same persistent SSH connection — limiting the practical attack surface.

1. Reconnaissance: Identify SSH servers with GSSAPIAuthentication yes configured (the default on RHEL), particularly those running RHEL 10 where GSSAPIDelegateCredentials also defaults to yes.
2. Establish SSH connection: Open a persistent SSH connection to the target server that supports multiple authentication attempts (controlled by MaxAuthTries).
3. Initiate failed GSSAPI exchange: Attempt GSSAPI authentication using a valid Kerberos ticket or crafted GSSAPI token that passes the initial exchange but fails the ssh_gssapi_userok authorization check, causing ssh_gssapi_storecreds to store delegated credentials in the connection's gssapi_client structure.
4. Perform subsequent authentication: On the same connection, authenticate successfully via a different method (e.g., password or public key), triggering interaction with the leftover GSSAPI credential state.
5. Access delegated credentials: If the server calls ssh_gssapi_storecreds again or the session inherits the stored credential context, the attacker's session may have access to the delegated Kerberos credentials, potentially usable for further access to Kerberos-protected services (Red Hat Bugzilla, Red Hat CVE).

• Logs: SSH authentication logs (/var/log/secure or journalctl -u sshd) showing a failed GSSAPI authentication attempt immediately followed by a successful login from the same source IP on the same connection session ID.
• Logs: sshd log entries referencing GSSAPI credential delegation (e.g., Delegating credentials) for sessions where the GSSAPI user check did not succeed.
• Network: Repeated SSH connections from the same source IP attempting GSSAPI authentication followed by alternative authentication methods in rapid succession.
• File System: Unexpected Kerberos credential cache files (e.g., /tmp/krb5cc_*) created under the SSH daemon's process context or owned by unexpected users.

Red Hat has confirmed a patch is available and tracked via Bugzilla 2553033. Until patching is applied, Red Hat recommends setting GSSAPIDelegateCredentials no in /etc/ssh/sshd_config where that option exists, or disabling GSSAPI authentication entirely by setting GSSAPIAuthentication no if Kerberos-based SSH authentication is not required in the environment. Additionally, restricting SSH access to trusted networks via firewall rules reduces exposure. Restart sshd after any configuration change (Red Hat CVE, Red Hat Bugzilla).

Red Hat credited Moritz Theile with discovering and reporting the vulnerability. Red Hat's own analysis clarifies that while delegated credentials are improperly stored, the leftover state does not directly authorize a later login — a nuance that somewhat limits the severity compared to a full authentication bypass (Red Hat CVE). No significant broader community or media commentary has been identified at this time.