CVE-2026-60001: OpenSSH Authentication Bypass Vulnerability

CVE-2026-60001 Overview

CVE-2026-60001 affects sshd in OpenSSH versions before 10.4. The daemon does not always honor the configured minimum authentication delay. This behavior weakens timing-based defenses that OpenSSH uses to obscure valid versus invalid authentication attempts. Attackers positioned on the network can leverage this timing inconsistency to accelerate brute-force attempts or infer information about account states. The issue is tracked as an uncontrolled resource consumption weakness [CWE-770].

Critical Impact
Remote attackers can bypass timing protections that normally throttle failed authentication attempts, enabling faster credential guessing and potential username enumeration against exposed SSH services.

Affected Products

OpenSSH sshd versions prior to 10.4
OpenSSH portable release prior to 10.4p1
Systems and Linux distributions bundling vulnerable OpenSSH server builds

Discovery Timeline

2026-07-08 - CVE-2026-60001 published to the National Vulnerability Database (NVD)
2026-07-08 - Last updated in NVD database

Technical Details for CVE-2026-60001

Vulnerability Analysis

OpenSSH enforces a minimum authentication delay to prevent attackers from distinguishing failed authentication outcomes through response timing. In vulnerable builds, sshd does not consistently apply this delay across all authentication paths. As a result, response times can vary based on whether a username is valid, whether a password check occurred, or whether an early rejection was triggered.

The weakness maps to [CWE-770] Allocation of Resources Without Limits or Throttling. Removing or shortening the authentication delay lifts a rate-limiting guardrail that protects against automated credential attacks. While the flaw does not directly grant code execution or disclose credentials, it degrades the effectiveness of anti-brute-force and anti-enumeration controls that operators rely on.

Root Cause

The root cause lies in the authentication path handling within sshd. Certain code branches return responses to the client before the configured minimum delay elapses. The delay logic is not uniformly applied to every failure or rejection scenario, allowing observable timing variation between authentication outcomes.

Attack Vector

Exploitation requires only network reachability to the SSH service, with no authentication or user interaction. An attacker measures response timing across authentication attempts to differentiate between valid and invalid usernames or to accelerate password-guessing throughput. Because the attack relies on timing analysis rather than a memory-corruption primitive, no exploitation code is required. See the OpenSSH Release Notes 10.4p1 and the OpenSSH Development Discussion for maintainer context on the fix.

Detection Methods for CVE-2026-60001

Indicators of Compromise

High volumes of failed SSH authentication attempts from single or distributed source addresses against sshd
Repeated short-duration SSH sessions closing immediately after the authentication banner exchange
Authentication attempts targeting many usernames with consistent, low-latency response patterns

Detection Strategies

Inventory OpenSSH server versions across the environment and flag any host running sshd earlier than 10.4 or 10.4p1
Parse /var/log/auth.log or journalctl -u ssh for spikes in Failed password and Invalid user events over short intervals
Correlate SSH connection metadata at the network layer to identify username enumeration patterns and timing-based probing

Monitoring Recommendations

Forward SSH authentication logs to a central log platform and alert on brute-force thresholds per source IP and per target account
Track connection rate and failed-authentication rate for internet-exposed SSH endpoints and baseline normal behavior
Monitor for outbound scanning activity from hosts that were the target of sustained SSH probing, which may indicate a successful compromise

How to Mitigate CVE-2026-60001

Immediate Actions Required

Upgrade OpenSSH to version 10.4 or later, or OpenSSH portable to 10.4p1, on all systems running sshd
Restrict SSH exposure to trusted networks using firewall rules, bastion hosts, or VPN-only access
Enforce key-based authentication and disable password authentication where feasible by setting PasswordAuthentication no in sshd_config
Apply account lockout and rate-limiting tools such as fail2ban or sshguard to blunt brute-force attempts

Patch Information

The issue is fixed in OpenSSH 10.4 and OpenSSH portable 10.4p1. Refer to the OpenSSH Release Notes 10.4p1 and the Openwall OSS-Security Update for details on the fix and coordinated disclosure. Linux distribution maintainers typically backport the fix; check vendor security advisories for backported package versions.

Workarounds

Front SSH services with a rate-limiting reverse proxy or firewall rule that throttles new connection attempts per source
Reduce MaxAuthTries and LoginGraceTime in sshd_config to limit attempts per connection and shorten unauthenticated session lifetimes
Require multi-factor authentication via PAM modules to ensure that credential guessing alone cannot grant access

bash

# Configuration example - harden sshd_config while patching
PasswordAuthentication no
PubkeyAuthentication yes
MaxAuthTries 3
LoginGraceTime 20
PermitRootLogin no

# Verify installed OpenSSH version
ssh -V

# Restart sshd after applying changes
sudo systemctl restart ssh