libssh CVE-2026-0966

Exploitation requires the target SSH server to have GSSAPI authentication explicitly enabled via 'GSSAPIAuthentication yes' in sshd_config (not the default in most distributions), AND server-side SSH logging verbosity set to SSH_LOG_PACKET (level 3) or higher (typically only enabled during debugging, not standard production configuration). The vulnerable code path is triggered during GSSAPI OID processing in authentication handshake when the server attempts to log received OID data. No authentication is required (PR:N), no user interaction needed (UI:N), and attack complexity is low (AC:L) once the prerequisites are met. Default SSH server configurations with GSSAPI disabled or logging at INFO/WARN levels are NOT exploitable via the remote GSSAPI vector, though applications directly calling ssh_get_hexa() or ssh_get_fingerprint_hash() APIs with zero-length input remain vulnerable. The vulnerability is limited to per-connection daemon processes - it does not enable persistent server compromise, privilege escalation, or data exfiltration.

Real-world risk is moderate despite the CVSS 8.2 score. The CVSS vector (AV:N/AC:L/PR:N/UI:N) indicates remote unauthenticated exploitation with low complexity, which initially suggests high urgency. However, multiple factors reduce practical risk: (1) Exploitation requires the server to enable GSSAPI authentication (not default in most SSH deployments) AND configure logging at SSH_LOG_PACKET level or higher (typically only used in debugging scenarios, not production). (2) EPSS score of 0.09% (25th percentile) indicates very low probability of exploitation in the wild. (3) SSVC framework shows 'Exploitation: none' with 'Technical Impact: partial' - the vulnerability only causes per-connection DoS, not systemic server failure or data compromise. (4) Impact is limited to Availability (A:H) with Low Integrity impact (I:L) but no Confidentiality breach (C:N). (5) Ubuntu assigned 'priority=low', confirming vendor assessment of limited real-world threat. (6) No KEV listing and no public POC identified. The vulnerability is automatable according to SSVC, meaning an attacker could script exploitation, but the narrow attack surface (GSSAPI+verbose logging) significantly constrains exposure. Organizations NOT using GSSAPI authentication or verbose logging can deprioritize. Those running SSH servers with GSSAPI enabled should prioritize patching to prevent potential targeted DoS attacks against authenticated services.

An unauthenticated remote attacker connects to an SSH server configured with GSSAPI authentication enabled and verbose logging (SSH_LOG_PACKET level 3+). During the SSH handshake, the attacker sends a crafted GSSAPI authentication request containing a zero-length OID payload. The server's libssh GSSAPI code attempts to log this OID by calling ssh_get_hexa() with the zero-length input, triggering a buffer under-read (CWE-124). The resulting memory access violation crashes the per-connection sshd daemon process, terminating the SSH session and potentially disrupting legitimate users if repeatedly exploited. No public proof-of-concept exists at time of analysis, but the CVSS AC:L (low complexity) and SSVC 'automatable: yes' assessment indicate exploitation could be scripted once the attack technique is developed.