AI analysis
OpenSSH sshd before 10.6 can keep credentials in place after a GSSAPIAuthentication attempt fails, instead of discarding them when that method does not succeed. The issue is reached over the network with no prior privileges or user interaction when a client tries GSSAPI (Kerberos) authentication and that attempt fails. CVSS rates the impact as high integrity and not confidentiality or availability, consistent with an authentication or authorization state that should not survive a failed GSSAPI login (CWE-669). It affects OpenSSH sshd builds older than 10.6 that have GSSAPI authentication in use, including systems covered by related distribution notices such as Ubuntu USN-8928-1. It is not listed in CISA KEV, and no public proof-of-concept is known.
What to do: Upgrade OpenSSH to 10.6 or later on every host that runs sshd. Until then, set GSSAPIAuthentication no (and restart sshd) wherever Kerberos/GSSAPI login is not required, and review authentication logs for failed GSSAPI attempts followed by unexpected successful logins.
Affected
| OpenBSD OpenSSH | sshd in OpenSSH before 10.6 |
Estimated exposure
large≈100,000–1,000,000+ GSSAPI-enabled OpenSSH servers (estimate; exact count unknown) — OpenSSH sshd is shipped on essentially all Unix-like servers and public scans show on the order of tens of millions of internet-reachable SSH services, but the bug only applies when GSSAPIAuthentication is enabled, which is off by default…
Order-of-magnitude estimate by the model from install counts, market share and public scan data it knows; verify before quoting.