CVE-2026-60000

What it actually does

OpenSSH sshd before 10.4 mishandles the MaxAuthTries limit when GSSAPIAuthentication is enabled. A remote, unauthenticated client can make excessive authentication attempts that are not constrained as intended, causing the SSH daemon to consume CPU, memory, process slots, connection capacity, or related authentication resources. The result is a network-reachable denial-of-service condition against SSH availability; the vulnerability does not provide code execution, privilege escalation, data disclosure, or integrity compromise based on the available description.

Why it matters to the business

Systems that rely on OpenSSH for remote administration can become slow or temporarily unreachable over SSH if exposed to repeated malicious authentication attempts. This can delay incident response, maintenance, deployments, automation, and emergency administrative access. The CVSS and EPSS values are low and there is no known KEV listing or reported exploit maturity, but the issue affects a widely deployed remote-access service and can still create operational disruption where SSH is internet-exposed or heavily used.

How an attack unfolds

An attacker identifies an SSH service running a vulnerable OpenSSH version with GSSAPIAuthentication enabled or otherwise reachable authentication behavior affected by the flaw. The attacker repeatedly opens SSH sessions and drives the authentication exchange through excessive GSSAPI-related attempts that should have been limited by MaxAuthTries. Because sshd mishandles that limit in affected versions, the server spends resources processing more authentication work than intended. By maintaining or repeating enough concurrent attempts, the attacker can degrade sshd responsiveness, exhaust connection or process limits, and prevent legitimate administrators or automation from establishing reliable SSH sessions. Successful exploitation requires network access to the SSH port and enough sustained traffic to create resource pressure; it is not known to yield shell access or compromise credentials.

How to fix it

Upgrade OpenSSH to version 10.4 or later when available from the operating system or appliance vendor. Because OpenSSH is commonly distributed as part of an OS package, apply the vendor security update for OpenSSH/sshd rather than relying only on upstream version strings, which may include backported fixes. If immediate patching is not possible, reduce exposure by disabling GSSAPIAuthentication where it is not required, limiting SSH access to trusted networks or VPNs, enforcing firewall or security-group allowlists, using rate limiting for new SSH connections, reducing unauthenticated connection pressure with MaxStartups and PerSourceMaxStartups where supported, and monitoring for authentication-flood behavior. Restart sshd after configuration or package changes using a method that preserves existing administrative access, and verify that emergency console access remains available before changing SSH settings.

How to confirm the fix worked

Confirm the installed OpenSSH package includes the vendor fix or is OpenSSH 10.4 or later. Check the runtime daemon version with sshd -V where supported, package manager metadata, or vendor advisory mapping. Review /etc/ssh/sshd_config and included configuration snippets for GSSAPIAuthentication; if not needed, verify it is disabled and that sshd has been reloaded or restarted. Validate externally that SSH remains reachable only from intended networks and that firewall/rate-limit controls are active. Perform a controlled authentication-attempt test from an authorized host to ensure MaxAuthTries behavior and connection throttling operate as expected without causing service degradation. Monitor CPU, memory, process count, and concurrent sshd sessions during the test.

Typical attack path

1. Scan for reachable SSH services, commonly on TCP/22 or organization-specific SSH ports.
2. Fingerprint the SSH banner or behavior to identify OpenSSH versions before 10.4.
3. Determine whether GSSAPIAuthentication is enabled or attempt GSSAPI authentication paths opportunistically.
4. Open many SSH connections and perform repeated excessive authentication attempts that exercise the MaxAuthTries mishandling.
5. Sustain or increase concurrent attempts until sshd resource consumption degrades service or blocks legitimate logins.
6. Repeat as needed to maintain denial of service or disrupt administrative access.

How to detect it

Investigate authentication and system logs for unusually high volumes of SSH connection attempts, repeated authentication failures, GSSAPI-related authentication messages, sshd child process churn, MaxStartups throttling, connection resets before authentication, or resource spikes correlated with inbound traffic to SSH. Useful sources include /var/log/auth.log, /var/log/secure, systemd journal entries for sshd, firewall logs, NetFlow/VPC flow logs, endpoint process telemetry, and infrastructure monitoring for CPU, memory, load average, process count, and TCP connection state. Look for many short-lived or concurrent TCP connections to SSH from one or more external IPs, especially where few or no successful logins follow. Because the vulnerability causes denial of service rather than post-compromise execution, evidence is likely to be volumetric and service-health related rather than malware artifacts. If threat hunting across historical data, focus on the period after publication and on systems running OpenSSH before 10.4 with GSSAPIAuthentication enabled.

• GSSAPIAuthentication yes
• sshd
• sshd-session
• Failed gssapi-with-mic
• Failed gssapi-keyex
• Postponed gssapi-with-mic
• Postponed gssapi-keyex
• maximum authentication attempts exceeded
• Too many authentication failures
• beginning MaxStartups throttling
• drop connection #
• Connection closed by authenticating user
• Disconnected from authenticating user
• pam_unix(sshd:auth): authentication failure
• /var/log/auth.log
• /var/log/secure
• /etc/ssh/sshd_config
• /etc/ssh/sshd_config.d/

What your security team should do

• Inventory internet-facing and production-critical SSH services and prioritize those running OpenSSH before 10.4, especially where GSSAPIAuthentication is enabled.
• Apply vendor OpenSSH updates or upgrade to OpenSSH 10.4 or later during the next available maintenance window, prioritizing administrative bastions, jump hosts, hypervisors, network appliances, and automation endpoints.
• Disable GSSAPIAuthentication unless it is explicitly required for Kerberos/GSSAPI-based SSH authentication.
• Restrict SSH exposure using allowlists, VPN access, bastion patterns, and network segmentation.
• Enable or tune SSH connection throttling controls such as MaxStartups, PerSourceMaxStartups, and firewall-level rate limits where supported.
• Add monitoring for spikes in failed SSH authentication, GSSAPI authentication attempts, concurrent unauthenticated sessions, sshd process count, and SSH port connection rates.
• Ensure out-of-band or console access is available for critical systems in case SSH becomes unavailable during an attack or remediation.
• Track vendor advisories because downstream packages may be fixed through backports without changing the visible OpenSSH upstream version.