CVE-2026-110924: Openssh: openssh: gssapi delegated credentials can be stored after a failed authentication
A flaw was found in OpenSSH sshd when GSSAPIAuthentication is enabled. A partial GSSAPI exchange left gssapiclient, including an exported name and credential, for a later authentication attempt on the same connection. sshgssapistorecreds stored delegated credentials even when sshgssapiuserok had not succeeded. The RHEL maintainer confirmed that this does not authorize a later login. The impact is storage of a delegated credential that userok did not accept. RHEL ships GSSAPIAuthentication yes. On RHEL 10, GSSAPIDelegateCredentials defaults to yes, and storecreds returns early only when that switch is off. This is not CVE-2026-60000 (MaxAuthTries and GSSAPI) and not CVE-2026-3497 (GSSAPI key exchange).
Other sources
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.
— MITRE
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Configuration
Disable GSSAPIDelegateCredentials so delegated credentials are not stored after a failed GSSAPI authentication attempt.
OpenSSH sshd GSSAPIDelegateCredentials = no
Event History
Frequently Asked Questions
Which systems are exposed to this issue?
Systems running OpenSSH sshd with GSSAPIAuthentication enabled are exposed to the credential-storage flaw. RHEL ships with GSSAPIAuthentication enabled, and RHEL 10 defaults GSSAPIDelegateCredentials to enabled.
What must occur for delegated credentials to be stored incorrectly?
A client must perform a partial or failed GSSAPI authentication exchange that leaves GSSAPI client state on the connection. If a later authentication attempt succeeds on that same connection, the previously delegated credential may have been stored even though the earlier GSSAPI authorization check did not succeed.
Does the leftover GSSAPI state allow an attacker to log in?
No. The RHEL maintainer confirmed that the leftover state does not authorize a later login; the impact is storage of a delegated credential that was not accepted by the user authorization check.
What configuration can reduce exposure if patching is not immediately possible?
Disable GSSAPI delegated credentials by setting GSSAPIDelegateCredentials off. On RHEL 10, the credential-storage path returns early when this switch is off.