CVE-2026-59851: libssh Auth Bypass Vulnerability

CVE-2026-59851 Overview

CVE-2026-59851 is an authorization flaw in libssh, the C library implementing the SSH protocol. On servers configured with GSSAPIKeyExchange enabled, the gssapi-keyex authentication path fails to verify whether the authenticated Kerberos principal is authorized to log in as the requested local user. Authenticated clients can leverage this gap to impersonate arbitrary users on the target system, including privileged accounts. The issue is classified under CWE-863: Incorrect Authorization and affects any application or appliance that embeds vulnerable versions of libssh with GSSAPI key exchange support.

Critical Impact
Authenticated attackers can bypass user authorization on libssh-based SSH servers with GSSAPIKeyExchange enabled and log in as arbitrary users, including root.

Affected Products

libssh versions supporting GSSAPI key exchange with GSSAPIKeyExchange enabled
Red Hat Enterprise Linux distributions shipping the affected libssh package (see Red Hat Security Errata RHSA-2026:42922)
Server applications and appliances that embed libssh for SSH server functionality with Kerberos authentication

Discovery Timeline

2026-07-21 - CVE-2026-59851 published to the National Vulnerability Database
2026-07-22 - Last updated in NVD database

Technical Details for CVE-2026-59851

Vulnerability Analysis

The flaw resides in the gssapi-keyex authentication method inside libssh. GSSAPI key exchange combines SSH key exchange with Kerberos-based authentication, allowing a client to prove its Kerberos identity as part of the transport-layer handshake. After a successful GSS key exchange, the SSH server should verify that the authenticated Kerberos principal is authorized to access the requested Unix account via krb5_kuserok() or equivalent authorization checks.

In vulnerable builds of libssh, this authorization step is absent from the gssapi-keyex path. The library treats a successful Kerberos authentication as sufficient proof to log in as any username the client requests, without confirming a mapping between the principal and the target local user. A user holding a valid Kerberos ticket for alice@REALM can therefore request a session as root, bob, or any other account on the server and be granted access.

Root Cause

The root cause is a missing authorization check [CWE-863] between authentication and session establishment. The gssapi-keyex code path does not invoke the principal-to-user mapping validation that is applied to the standard gssapi-with-mic userauth method. Successful GSSAPI credential validation is conflated with successful user authorization.

Attack Vector

Exploitation requires an attacker to hold valid Kerberos credentials accepted by the target realm and to reach a libssh-based SSH server with GSSAPIKeyExchange yes configured. The attacker initiates an SSH connection specifying an arbitrary target username, completes GSSAPI key exchange with their own ticket, and is granted an interactive session or command execution context as the requested user. No further privilege escalation primitives are needed when the requested user is root or another privileged account. See the Red Hat CVE entry for vendor analysis.

Detection Methods for CVE-2026-59851

Indicators of Compromise

SSH session logins where the authenticated Kerberos principal does not match the local target username or any entry in the target user's ~/.k5login file.
Successful gssapi-keyex authentications for privileged accounts such as root originating from principals not typically mapped to those accounts.
Unexpected Kerberos service ticket requests for host/<server>@REALM followed by SSH logins as multiple distinct local users from the same source.

Detection Strategies

Correlate SSH server authentication logs with Kerberos KDC logs to identify mismatches between the authenticating principal and the local account entered at login.
Alert on any successful gssapi-keyex authentication in libssh-based services where the principal name does not correspond to the target user through krb5_kuserok semantics.
Baseline typical principal-to-user mappings per host and flag deviations, particularly logins to shared or administrative accounts.

Monitoring Recommendations

Forward SSH server logs and KDC audit logs to a centralized SIEM or data lake for cross-source correlation and retention.
Monitor configuration state of /etc/ssh/sshd_config and libssh-consuming applications for the presence of GSSAPIKeyExchange yes on hosts that do not require it.
Track process execution and privilege changes following SSH sessions established via GSSAPI to detect post-authentication misuse.

How to Mitigate CVE-2026-59851

Immediate Actions Required

Inventory all systems running libssh-based SSH servers and identify those with GSSAPIKeyExchange enabled.
Apply vendor patches for libssh as soon as they are available for your distribution; Red Hat customers should follow RHSA-2026:42922.
Rotate Kerberos keytabs and review recent authentication logs on exposed hosts for suspicious cross-user logins.

Patch Information

Red Hat has published fixed packages via RHSA-2026:42922. Additional context is available in the Red Hat Bugzilla report and the Red Hat CVE page. Administrators using other distributions or embedding libssh directly should track upstream libssh releases and rebuild affected products with the fixed library.

Workarounds

Disable GSSAPI key exchange by setting GSSAPIKeyExchange no in the SSH server configuration until a patched libssh is deployed.
Restrict access to SSH services to trusted networks using firewall rules or host-based access controls while the vulnerability is unpatched.
Enforce strict ~/.k5login and auth_to_local rules on adjacent OpenSSH-based hosts to reduce lateral movement risk from any compromised account.

bash

# Disable GSSAPI key exchange in sshd_config as a temporary workaround
sudo sed -i 's/^#*GSSAPIKeyExchange.*/GSSAPIKeyExchange no/' /etc/ssh/sshd_config
sudo sshd -t && sudo systemctl restart sshd