CVE-2026-60001

What it actually does

OpenSSH sshd versions before 10.4 may fail to consistently enforce the configured minimum authentication delay. That delay is intended to slow repeated authentication attempts and reduce the effectiveness of rapid credential guessing or timing-based authentication probing. When the delay is not honored, a remote unauthenticated attacker can receive faster authentication failure responses than intended, enabling higher-rate password, keyboard-interactive, or other authentication attempts against exposed SSH services. The CVSS impact indicates no direct confidentiality impact, but limited integrity and availability impact may occur through increased likelihood of unauthorized login attempts succeeding or through authentication-service load from accelerated attempts.

Why it matters to the business

Organizations exposing vulnerable OpenSSH services may have weaker protection against automated login attempts than expected. This can increase the risk of account compromise where passwords, reused credentials, or weak authentication are present, and can raise operational load from brute-force activity against internet-facing SSH. The vulnerability is not currently listed in CISA KEV, has low EPSS, and no public exploit maturity is reported, so urgency is moderate rather than emergency; however, SSH is widely deployed and often internet-accessible, so routine patching and hardening should be prioritized.

How an attack unfolds

An attacker identifies a host running sshd from OpenSSH before 10.4 and attempts repeated SSH authentication. Because the server may not consistently apply the minimum authentication delay after failed attempts, the attacker can iterate through credential guesses faster than the administrator intended. The attacker may combine this with username discovery from other sources, password reuse lists, default credentials, or leaked keys. If a valid credential is found and additional protections such as MFA, key-only authentication, rate limiting, or fail2ban-style blocking are absent, the attacker logs in over SSH and gains the privileges associated with that account. Even without a successful login, the reduced delay can increase authentication traffic volume and create noise or resource pressure on exposed SSH services.

How to fix it

Upgrade OpenSSH to version 10.4 or later wherever sshd is used. If a vendor distribution backports security fixes without changing the upstream OpenSSH version string, apply the vendor-provided security update and verify package changelogs/advisories rather than relying only on the SSH banner. As compensating controls, disable password authentication where feasible, require public-key or hardware-backed authentication, restrict SSH exposure with firewalls or VPN access, enforce MFA where supported, limit allowed users/groups, reduce MaxAuthTries, disable root login, and deploy connection throttling or blocking controls such as fail2ban, sshguard, or equivalent network rate limits.

How to confirm the fix worked

Confirm remediation by checking installed OpenSSH packages and vendor advisory status on all systems running sshd. Validate that sshd is OpenSSH 10.4 or later, or that the operating-system vendor has backported the fix. Restart or reload sshd after patching and verify the active daemon binary is the updated version. From a controlled test system, perform repeated failed SSH authentications and confirm normal defensive controls trigger as expected, including authentication delays, account lockout where configured, rate limiting, and blocking. Also confirm hardening settings such as PasswordAuthentication no, PermitRootLogin no, MaxAuthTries, AllowUsers or AllowGroups, and firewall restrictions are in place where appropriate.

Typical attack path

1. Scan for hosts exposing SSH, commonly on TCP port 22 or alternate SSH ports.
2. Fingerprint the SSH banner or behavior to identify OpenSSH versions before 10.4.
3. Perform repeated authentication attempts using password lists, known usernames, leaked credentials, or default credential combinations.
4. Benefit from faster-than-expected failed authentication responses when the minimum delay is not enforced.
5. Obtain successful SSH access if a valid credential is guessed or reused.
6. Use the compromised account for persistence, privilege escalation, lateral movement, or data access, depending on local permissions.

How to detect it

Review SSH authentication logs for evidence of accelerated brute-force or credential-stuffing activity, especially on systems running OpenSSH before 10.4. Relevant log sources include Linux auth logs such as /var/log/auth.log, /var/log/secure, journald units for ssh or sshd, BSD auth logs, EDR process/network telemetry, firewall logs, fail2ban or sshguard logs, and VPN or bastion access logs if SSH is proxied. Look for repeated failed password or keyboard-interactive attempts from the same source, many usernames attempted from one source, one username targeted by many sources, successful logins shortly after a burst of failures, root login attempts, and spikes in inbound TCP/22 or alternate SSH-port connections. Because this issue does not produce a unique exploit payload, detection should focus on authentication behavior and post-login activity such as unusual shell sessions, unexpected sudo usage, new authorized_keys entries, new local users, modified sshd_config, or outbound connections from recently accessed accounts.

• Failed password for
• Failed password for invalid user
• Invalid user
• authentication failure
• PAM: Authentication failure
• Maximum authentication attempts exceeded
• Connection closed by authenticating user
• Connection closed by invalid user
• Disconnected from authenticating user
• Disconnected from invalid user
• Accepted password for
• Accepted publickey for
• Accepted keyboard-interactive/pam for
• error: maximum authentication attempts exceeded
• sshd
• /var/log/auth.log
• /var/log/secure
• journalctl -u ssh
• journalctl -u sshd
• /etc/ssh/sshd_config
• /etc/ssh/authorized_keys
• .ssh/authorized_keys
• /var/log/fail2ban.log
• fail2ban.actions
• sshguard

What your security team should do

• Inventory externally reachable SSH services and prioritize patching OpenSSH before 10.4 on internet-facing systems.
• Upgrade to OpenSSH 10.4 or apply the relevant vendor backported security update, then restart sshd.
• Harden SSH authentication by disabling password login where possible and requiring key-based or MFA-backed access.
• Restrict SSH access to trusted networks, bastion hosts, VPNs, or zero-trust access brokers rather than exposing it broadly to the internet.
• Deploy or tune brute-force protections such as fail2ban, sshguard, PAM lockout, firewall rate limits, and SIEM alerting for repeated failures.
• Review recent SSH authentication logs for unusually high-volume failed attempts, successful logins after repeated failures, and access from unfamiliar networks.
• Monitor vendor advisories because OpenSSH version banners may not reflect backported fixes in Linux and BSD distributions.