OpenSSH CVE-2026-110924

Exploitation requires the SSH server to have GSSAPI authentication enabled (GSSAPIAuthentication yes) with credential delegation in use - this is NOT the default OpenSSH configuration and is typically only present in Kerberos/Active Directory-integrated deployments. The attacker must also induce the specific sequence of a failed GSSAPI attempt followed by a successful login on the same connection to inherit the leftover delegated credential state, which is reflected in the AC:H rating. Limiting factors: non-default GSSAPI configuration, dependency on a Kerberos infrastructure, and the race/ordering condition required to leave credentials stored all substantially narrow real-world exploitability despite the network attack vector.

This is a medium-severity issue (CVSS 4.8, CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N) with no corroborating exploitation signals - no EPSS score, KEV listing, or POC was provided in the input, so it falls under 'no public exploit identified at time of analysis'. While the vector is network-based and nominally unauthenticated (PR:N), the high attack complexity (AC:H) accurately reflects the real barrier: the flaw is a credential-cleanup race (CWE-459, incomplete cleanup) that only manifests in a narrow sequence where a failed GSSAPI attempt leaves delegated credentials attached to the connection and a subsequent successful login inherits that stale, unauthorized state. The impact is bounded (C:L/I:L, A:N) rather than full compromise. The dominant limiting factor is that GSSAPI authentication must be explicitly enabled - this is NOT the OpenSSH default - so real-world exposure is confined to Kerberos/GSSAPI-integrated environments. Net: a legitimate correctness/authorization-state bug worth patching in GSSAPI-enabled fleets, but not a drop-everything priority; the CVSS medium rating, absent any exploitation evidence, correctly characterizes it as lower real-world risk than the network vector alone might suggest.

In an environment where sshd has GSSAPI authentication enabled, an attacker triggers a failed GSSAPI authentication attempt that nonetheless causes delegated credentials to remain stored on the connection. A later successful login over that same connection then operates with the leftover delegated credential state that was never authorized, potentially allowing access to Kerberos-delegated resources it should not have. No public exploit code is known, and the high attack complexity plus required non-default GSSAPI configuration make reliable exploitation difficult.