SSHole OpenSSH flaw is being exploited against accounts on affected Linux systems
Threat actors are attempting to exploit SSHole, a high-severity authentication bypass in OpenSSH tracked as CVE-2026-123158. The flaw can allow access to certain accounts by submitting an unusually long password, including accounts that administrators expect to be passwordless. OpenSSH version 10.6p2 contains the fix, and Alpine Linux has urged users to update and restart the SSH service.
WatchTowr and Previdian reported exploitation activity over the weekend. WatchTowr said the vulnerability had so far been adopted by botnets and crypto miners. Previdian reported 20 exploitation attempts from 13 unique IP addresses across nine countries. Its sensors first observed activity on November 6, 2026, and most recently observed it on November 8. GreyNoise and Defused have also reported attempts.
How the authentication bypass works
The bug involves how OpenSSH interprets the result of password-hash processing. In affected configurations, sshd checks a submitted password by hashing it against a stored hash associated with the requested username. If an account has no usable password hash, sshd may use a salt from another account’s hash while processing the attempt.
The issue arises on some Linux systems using the musl C library, with Pluggable Authentication Module (PAM) disabled. For passwords longer than 256 bytes, musl’s crypt() function can fail and return an asterisk rather than NULL. Where the target account’s stored password field is also an asterisk, the returned value can match that field. OpenSSH may then treat the password check as successful.
The practical exposure depends on the operating system and account configuration. The source identifies Alpine, Buildroot, OpenWrt and Yocto among distributions that may be affected under the relevant conditions. The vulnerability is not described as a general bypass against every OpenSSH installation: it concerns systems using musl with PAM disabled and accounts whose password handling creates the vulnerable comparison.
On Alpine, potentially affected accounts include root, key-only users created with adduser without a password, the Alpine user in official tiny-cloud images, and users supplied by a directory service through musl-nscd. Root is a particularly important case because it should not accept a password, but on some affected systems the account can still accept one.
Patch and review exposure
Organizations should prioritize upgrading affected installations to OpenSSH 10.6p2 and restarting sshd so the patched service is running. Alpine has specifically advised users to apply the update and restart the daemon as soon as possible. Security teams should verify the installed OpenSSH version and determine whether systems use musl and have PAM disabled, then identify accounts and images that may match the affected conditions.
Where an immediate update is not possible, the stated mitigations are to disable password authentication or disable SSH. Password authentication is enabled by default in OpenSSH, according to the supplied vulnerability information. Any temporary change should be checked against operational access requirements, particularly where administrators rely on SSH for remote management. Disabling SSH removes that remote access path but may not be appropriate for every system.
Defenders should also review authentication logs for unusual requests that could indicate attempted exploitation. The reported activity demonstrates that attackers are probing for the flaw, but the available reports do not establish that every attempt succeeded or that a particular organization was compromised. Treat unexpected SSH authentication activity as a reason to investigate the targeted host, account, and surrounding access events.
The incident highlights why passwordless account configuration and the underlying authentication stack need to be considered together. A user account intended for key-based access may still be exposed if the operating system’s handling of an absent password hash interacts with the vulnerable OpenSSH behavior. Inventorying affected distributions, checking PAM configuration, applying the vendor update, and validating SSH authentication controls are the immediate defensive priorities.
