A newly disclosed OpenSSH vulnerability, nicknamed SSHole, is already being exploited in the wild. The flaw, tracked as CVE-2026-123158 and carrying a CVSS score of 8.1, lets unauthenticated attackers log in to certain Linux accounts that have no usable password set. Security firm Previdian observed the first exploitation attempt less than nine hours after the vulnerability was published, and confirmed successful root access on an Alpine Linux honeypot.
The issue affects Linux systems running OpenSSH on the musl C library with Pluggable Authentication Modules (PAM) disabled. Alpine Linux’s default OpenSSH server configuration is among the affected setups. An attacker can send an oversized password—between 257 and 1,024 bytes—to trigger the bug and gain access to accounts configured with an asterisk (*) as their password hash. This means attackers do not need to steal SSH keys or valid credentials to obtain access.
SSHole stems from password-handling behavior linked to a 2016 patch for CVE-2016-6210, a username-enumeration flaw. Under the specific conditions, OpenSSH mistakenly treats a failed password-hashing operation as successful authentication because it produces the same asterisk value used to mark password-disabled accounts. The SSH daemon then compares that value with the account’s stored password field and allows the login. Importantly, the flaw does not bypass passwords on accounts that have valid password hashes.
The consequences depend heavily on the privileges of the compromised account. A successful attack grants the attacker the permissions already held by that account, which could include access to deployment credentials, application secrets, and connected infrastructure. From there, intruders may move laterally across systems or disrupt services. The vulnerability does not affect Dropbear, glibc-based Linux distributions, non-Linux systems, or systems that authenticate passwords through PAM.
Administrators should act quickly by installing OpenSSH 10.6p2 or their distribution’s patched package and restarting the sshd service. Alpine also advises reviewing /var/log/messages for “Accepted password for” entries involving accounts that should not accept password logins, including root, Alpine, or key-only users. Administrators should inspect recent users, files, authorized keys, and doas usage; if a suspicious login cannot be ruled out, the system should be treated as compromised.
Read the original article: