CVE-2026-59998

What it actually does

OpenSSH sshd versions before 10.4 have a security-relevant behavior where the GSSAPIStrictAcceptorCheck setting does not provide its intended protection when the SSH server participates in a Windows Active Directory Kerberos environment. GSSAPI/Kerberos authentication can therefore accept credentials in cases where administrators may expect the server to strictly validate the service acceptor identity. The practical impact is limited by the need for a suitable Kerberos/Active Directory setup and valid Kerberos material, but successful abuse can weaken authentication boundary assumptions and may allow unauthorized or unintended SSH access paths with limited confidentiality and integrity impact.

Why it matters to the business

Organizations using OpenSSH with Kerberos/GSSAPI authentication in Windows Active Directory environments may have a false sense that strict acceptor checking is enforcing service identity constraints. This can create exposure to unintended SSH logins, lateral movement, or access policy bypass in environments that rely on Kerberos-based SSH authentication. The current public exploitation signal is low: EPSS is 0.0018, the issue is not listed in CISA KEV, ransomware use is not reported, and no public exploit maturity is indicated. However, because OpenSSH is widely deployed and authentication controls are high-value, affected AD-integrated SSH servers should still be identified and upgraded during normal vulnerability remediation cycles.

How an attack unfolds

An attacker first needs network reachability to an SSH service that is using OpenSSH before 10.4 and has GSSAPI/Kerberos authentication enabled in a Windows Active Directory context. The attacker then obtains or already possesses Kerberos credentials or tickets that can be presented to the SSH service. Because the strict acceptor check does not have the expected effect in this environment, the server may accept GSSAPI authentication in scenarios that administrators believed would be rejected based on service identity validation. If accepted, the attacker gains an SSH session as the mapped account and can read or modify data available to that account, pivot further, or use the access to support broader lateral movement. The attack is not a simple unauthenticated remote code execution path; it is configuration- and environment-dependent and requires Kerberos/GSSAPI conditions that make exploitation higher complexity.

How to fix it

Upgrade OpenSSH sshd to version 10.4 or later when available from the operating system or vendor package repository. If vendor backports are used, verify that the package advisory explicitly includes the fix for this issue even if the upstream OpenSSH version string remains below 10.4. For systems that do not require Kerberos/GSSAPI SSH authentication, disable it by setting GSSAPIAuthentication no in sshd_config and restarting or reloading sshd. Where GSSAPI is required, review Kerberos service principal names, keytabs, AD computer account configuration, and SSH account mapping to ensure authentication behavior matches policy. Restrict SSH network exposure with firewalls, VPNs, bastions, or allowlists, and enforce least privilege for accounts permitted to log in via SSH.

How to confirm the fix worked

Confirm the installed OpenSSH server package includes the fix by checking the vendor advisory/package changelog or verifying OpenSSH 10.4 or later. Validate runtime configuration with sshd -T and confirm whether gssapiauthentication is enabled. Review sshd_config and included configuration files for GSSAPIAuthentication and GSSAPIStrictAcceptorCheck settings. In AD-integrated environments, perform controlled Kerberos/GSSAPI SSH authentication tests to verify that service identity validation behaves as expected after upgrade or mitigation. Confirm sshd was restarted after package or configuration changes, and review authentication logs to ensure only expected GSSAPI logins are succeeding.

Typical attack path

1. Identify internet-facing or internal SSH servers running OpenSSH before 10.4.
2. Determine whether SSH GSSAPI/Kerberos authentication is enabled and whether the server is joined to or integrated with Windows Active Directory.
3. Acquire usable Kerberos credentials, service tickets, delegated credentials, or account access through prior compromise or legitimate access abuse.
4. Attempt SSH authentication using GSSAPI, targeting cases where service acceptor identity validation should normally prevent acceptance.
5. Establish an SSH session if the server accepts the Kerberos authentication unexpectedly.
6. Use the resulting account privileges to access data, run commands, or move laterally within the environment.

How to detect it

To determine whether this was already exploited, review SSH authentication logs on Linux and Unix systems, commonly /var/log/auth.log, /var/log/secure, journald entries for sshd, and centralized SIEM records. Focus on successful GSSAPI/Kerberos SSH authentications, especially the method gssapi-with-mic, from unusual source IPs, to privileged or rarely used accounts, or at abnormal times. Compare successful GSSAPI logins against expected administrator activity, bastion access records, VPN logs, Kerberos KDC logs, and Active Directory domain controller security events. In Windows AD, review Kerberos ticket activity associated with SSH service principals and host accounts, looking for unusual service ticket requests, anomalous client hosts, and account logons that align with SSH session times. On the SSH server, inspect shell history, command audit logs, sudo logs, file modification timelines, new authorized_keys files, new local users, persistence mechanisms, and outbound connections following any suspicious GSSAPI login. There are no widely reported public exploit-specific payload strings or malware artifacts for this issue; detection should be behavior-based around unexpected Kerberos/GSSAPI SSH authentication and subsequent account activity.

• Accepted gssapi-with-mic
• Postponed gssapi-with-mic
• gssapi-with-mic
• GSSAPIAuthentication yes
• GSSAPIStrictAcceptorCheck
• /var/log/auth.log
• /var/log/secure
• sshd_config

What your security team should do

• Inventory SSH servers using OpenSSH before 10.4, prioritizing systems joined to or integrated with Windows Active Directory and systems with GSSAPIAuthentication enabled.
• Upgrade affected OpenSSH packages to a fixed vendor release or OpenSSH 10.4 or later.
• If Kerberos/GSSAPI SSH authentication is not required, disable it and restart sshd.
• Review AD Kerberos service principals, keytabs, SSH login mappings, and privileged accounts permitted to authenticate over SSH.
• Limit SSH exposure to trusted management networks, bastions, or VPN access paths.
• Monitor for unexpected successful gssapi-with-mic SSH logins, especially from unusual source hosts, outside normal administration windows, or to privileged accounts.
• Because exploitation evidence is currently low and the issue is not in KEV, prioritize based on exposure and use of AD/GSSAPI rather than treating it as an emergency internet-wide RCE event.