REDHAT-BUG-2553033: Medium severity OpenSSH OpenSSH vulnerability
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).
Affected Software
Event History
Frequently Asked Questions
Which systems are most exposed to this issue?
RHEL systems with GSSAPIAuthentication enabled are affected by the flawed credential handling path. RHEL ships with GSSAPIAuthentication enabled, and RHEL 10 is particularly relevant because GSSAPIDelegateCredentials defaults to enabled.
What must occur for delegated credentials to be stored improperly?
A client must perform a partial GSSAPI exchange on an SSH connection and delegate credentials. The GSSAPI user authorization check must not have succeeded, yet the implementation can still store the delegated credential for a later authentication attempt on that same connection.
Does this allow an attacker to gain authorization for a later SSH login?
No. The RHEL maintainer confirmed that the issue does not authorize a later login; the impact described is storage of a delegated credential that was not accepted by the user authorization check.
Is there a configuration-based mitigation if patching is not immediately possible?
Disabling GSSAPIDelegateCredentials prevents credential storage through this path, because storecreds returns early when that switch is off. Disabling GSSAPIAuthentication would also remove the affected authentication mechanism.