OpenSSH sshd: GSSAPI credentials and authentication state persist after a failed attempt

CVSS 2.2CVE-2026-106553Kernel, userspace & hypervisor+1 more CVEscurated

Impact

OpenSSH split this across two ids in the same 10.6 release - CVE-2026-106553 (credentials incorrectly persist after a failed GSSAPIAuthentication attempt) and CVE-2026-106555 (GSSAPI authentication state persists across attempts). Both are the same defect class in the same code path, carry the same score and vector, and are fixed by the same upgrade. State that should be discarded when an authentication attempt fails is carried forward, which the record scores as a low confidentiality impact. This only applies to sites that enable GSSAPIAuthentication - typically HPC centers and enterprises with Kerberos single sign-on in front of their login and compute nodes - and it is off by default. Where it is on, it is on every login node in the cluster.

Who can reach it

Local vector per the record, low privileges plus user interaction, against an sshd configured with GSSAPIAuthentication yes. Sites that leave GSSAPI disabled are not affected.

What to do

Upgrade to OpenSSH 10.6 or a distribution backport and restart sshd on login and management nodes. If Kerberos SSO is not actually in use, set GSSAPIAuthentication no, which removes the exposure without waiting for the package. Daemon restart only - no drain or reboot.

Also covers 1 CVE

The vendor assigned a separate id to each affected code path. They share this advisory, this score and this fix, so they are one entry here.

CVE-2026-106555

References

https://nvd.nist.gov/vuln/detail/CVE-2026-106553 https://nvd.nist.gov/vuln/detail/CVE-2026-106555 https://www.openssh.com/releasenotes.html#10.6

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.