CVE-2026-59998: OpenSSH GSSAPI Security Vulnerability

CVE-2026-59998 Overview

CVE-2026-59998 affects sshd in OpenSSH versions before 10.4. The vulnerability stems from an undocumented, security-relevant behavior in the Generic Security Services Application Program Interface (GSSAPI) authentication path. Specifically, the GSSAPIStrictAcceptorCheck directive has no effect when the SSH server is joined to a Windows Active Directory (AD) environment.

Administrators relying on GSSAPIStrictAcceptorCheck to constrain acceptor credentials on AD-integrated hosts receive weaker enforcement than the configuration implies. The issue is classified under CWE-573: Improper Following of Specification by Caller.

Critical Impact
On OpenSSH servers running in Windows Active Directory, GSSAPIStrictAcceptorCheck is silently ignored, weakening GSSAPI authentication guarantees for confidentiality and integrity.

Affected Products

OpenSSH sshd versions prior to 10.4
OpenSSH deployments configured with GSSAPI authentication against Windows Active Directory
OpenSSH portable builds shipped in Linux and Unix distributions predating the 10.4p1 release

Discovery Timeline

2026-07-08 - CVE-2026-59998 published to NVD
2026-07-08 - Last updated in NVD database

Technical Details for CVE-2026-59998

Vulnerability Analysis

OpenSSH's GSSAPIStrictAcceptorCheck directive instructs sshd to verify that the acceptor credential presented during GSSAPI authentication matches the host principal for the server. When enabled, it constrains which Kerberos service principal names (SPNs) the daemon will accept, reducing the impact of credential misconfiguration or principal substitution.

In versions before 10.4, this control is not honored when the server runs inside a Windows Active Directory realm. The directive's setting becomes irrelevant, and the daemon accepts acceptor credentials that a strict check would otherwise reject. Because the behavior is undocumented, operators cannot infer the reduced enforcement from the configuration file alone.

Exploitation requires network access to the SSH service and a valid position within the Kerberos/AD trust chain. The attack complexity is high, and successful abuse yields limited confidentiality and integrity impact rather than full session takeover.

Root Cause

The defect is a specification-adherence failure [CWE-573]. The GSSAPI acceptor validation path in sshd short-circuits its strict-check logic when the underlying Kerberos library resolves credentials via an AD key distribution center (KDC). The configured value of GSSAPIStrictAcceptorCheck is not applied on that code path.

Attack Vector

An attacker with the ability to present GSSAPI credentials to the target sshd — for example, through a compromised or misconfigured service principal in the same AD forest — can complete GSSAPI authentication that a strict acceptor check would have refused. No user interaction is required, and authentication proceeds over the network. Refer to the OpenSSH Release Notes 10.4p1 and the OpenWall OSS Security Mailing List post for the upstream description.

No public proof-of-concept code is available, and no verified exploitation code is published in the referenced advisories.

Detection Methods for CVE-2026-59998

Indicators of Compromise

Successful GSSAPI/Kerberos authentications to sshd from service principals that should be outside the host's expected acceptor set.
sshd log entries showing gssapi-with-mic authentication succeeding on AD-joined hosts where GSSAPIStrictAcceptorCheck yes is configured yet non-host SPNs are accepted.
Kerberos ticket-granting service (TGS) requests for host/ SPNs that do not match the local system's fully qualified domain name.

Detection Strategies

Inventory OpenSSH servers and identify those running versions below 10.4 that are joined to Active Directory using sshd -V or package metadata.
Correlate sshd authentication events with Windows Event ID 4769 (Kerberos service ticket requests) to flag mismatches between requested SPNs and the target host.
Audit sshd_config for GSSAPIAuthentication yes combined with GSSAPIStrictAcceptorCheck yes on AD-integrated hosts to identify systems relying on the ignored control.

Monitoring Recommendations

Forward sshd authentication logs and Windows Kerberos audit logs to a central analytics platform for cross-source correlation.
Alert on GSSAPI logins from principals outside an approved allowlist, particularly on privileged hosts.
Track OpenSSH package versions across the fleet and generate drift alerts when hosts fall below 10.4p1.

How to Mitigate CVE-2026-59998

Immediate Actions Required

Upgrade OpenSSH to version 10.4 or later, which restores GSSAPIStrictAcceptorCheck enforcement in AD environments.
Review every AD-joined host with GSSAPIAuthentication yes and confirm the acceptor principal set matches operational expectations.
Rotate host keytabs and remove stale or duplicate SPNs that could be leveraged to satisfy relaxed acceptor checks.

Patch Information

The fix ships in OpenSSH 10.4p1. See the OpenSSH Release Notes 10.4p1 and the upstream OpenSSH Development Discussion for change details. Apply distribution updates that incorporate the 10.4p1 source or the equivalent backport.

Workarounds

Disable GSSAPI authentication on AD-joined sshd instances until patched by setting GSSAPIAuthentication no in sshd_config.
Restrict inbound SSH to trusted management networks using host firewalls or network access control lists to limit exposure of GSSAPI endpoints.
Constrain the sshd service account's keytab to only the intended host/ SPN and remove additional principals that could be accepted under relaxed checks.

bash

# Configuration example: disable GSSAPI until the OpenSSH 10.4p1 update is applied
# /etc/ssh/sshd_config
GSSAPIAuthentication no
GSSAPICleanupCredentials yes

# After patching to OpenSSH >= 10.4p1, re-enable with strict acceptor checking
# GSSAPIAuthentication yes
# GSSAPIStrictAcceptorCheck yes

# Validate and reload
sshd -t && systemctl reload sshd