Previdian detects SSHole exploit attempts against OpenSSH within hours of disclosure

Previdian said its sensors caught the first exploit attempt against OpenSSH flaw CVE-2026-123158, nicknamed SSHole, less than nine hours after disclosure, and confirmed that an Alpine Linux honeypot allowed successful root access.

CVE-2026-123158, also known as sshole, is an OpenSSH authentication bypass rated CVSS 8.1. The flaw affects Linux systems running OpenSSH built with the musl C library and with Pluggable Authentication Modules disabled, including Alpine Linux‘s default OpenSSH server configuration. Systems based on glibc such as Debian, Ubuntu and Fedora, setups using PAM, Dropbear and OpenBSD are not affected. ox.security described the flaw as an authentication logic failure caused by interaction between OpenSSH and libc, not a cryptographic weakness or memory-corruption vulnerability.

An unauthenticated attacker can submit a long password, from 257 to 1,024 bytes, to a password-disabled account so the hashing step fails. When hashing fails, the result is an asterisk that matches the stored asterisk for the account’s password entry, leading sshd to accept the login. Exploitation works only when password authentication is enabled, the target account shows an asterisk in its password field, and at least one other local account holds a usable password hash. The flaw does not let attackers bypass passwords on accounts carrying valid password hashes.

Previdian sensors recorded eight exploitation attempts from one Japan-based IP address, 89.116.89[.]18, and every attempt was caught by a single sensor. Ryan Dewhurst said, “Our first observed attempt arrived less than nine hours after CVE publication,”. The intruder submitted passwords that are too large to defeat authentication and ran reconnaissance commands such as id, uname and hostname over non-interactive SSH sessions.

Safe Security said, “A successful SSHole attack grants access with the compromised account’s existing permissions,” and that the effect for enterprise hinges on the compromised account’s privilege level. Hunter Strategy said the access gained inherits the compromised account’s permissions, though the bypass does not automatically confer root, and said the observed activity demonstrates exploitation of a deliberately exposed honeypot rather than widespread production compromise.

The issue dates to a 2016 OpenSSH change made for username enumeration flaw CVE-2016-6210, which altered password handling for accounts lacking usable password hashes. In 2016, OpenSSH modified sshd so it borrows another account’s salt and hashes the password regardless for accounts without usable password hashes. Since 2012, musl’s crypt() function has rejected SHA-256 and SHA-512 passwords over 256 bytes, returning an asterisk when hashing fails. Ars Technica called the vulnerability decade-old.

Özgün Kültekin of Wakefield discovered the flaw and published details and reported the vulnerability to OpenSSH.

ox.security said routers and embedded devices run musl-based systems too, while Alpine is widely used in cloud environments, containers and lightweight infrastructure. ox.security said container systems without an OpenSSH server are not affected, nor are machines missing the required local password-hash configuration. Accounts with! rather than * in the password field are also immune, and Ars Technica said additional distributions may be affected when they run OpenSSH built with musl but without PAM.

From Alpine Linux 3.16 onward, the default root account used an asterisk in its password field. An asterisk has appeared in the root password field since around Alpine 3.16, and OpenSSH’s default PermitRootLogin setting blocks direct root login unless an administrator changed it. Özgün Kültekin explained that on Alpine’s official AWS and Azure images, the default alpine user has passwordless doas privileges, which means access to that account can effectively produce root.

SOCRadar called indirect root access the larger concern and said affected Alpine cloud images run versions 3.18.11 through 3.24.3, and said key-only users created without a password, along with directory-service users arriving through musl-nscd, match the target account profile.

OpenSSH released version 10.6p2 on November 5, 2026, to address the vulnerability, and Alpine Linux shipped patched packages for branches 3.16 through edge that same day, including releases no longer supported. Once administrators install the updated package, the running sshd binary stays in place, so administrators must restart sshd for the fix to take effect. Alpine administrators can apply the fix using apk upgrade -U -a and then run rc-service sshd restart. OpenSSH developer Damien Miller urged anyone running musl-based Linux without PAM to set PasswordAuthentication to no or disable SSH immediately.

When patching cannot happen right away, turn off password authentication or limit SSH access. Administrators should review /var/log/messages for sshd entries that show Accepted password on accounts not meant for password logins, such as alpine, root and key-only users. Teams should check exposed systems for doas activity, newly created users, new files and authorized keys, treating the machine as compromised when a login cannot be ruled out.

Teams should rebuild Docker and cloud images from a fixed base and redeploy, because updating a running server does not replace the package inside images. Close public and unused ports and require VPN connections where possible, reducing the login-bypass attack surface. Teams should avoid cloning unverified exploit or scanner scripts from public repositories or social media, and should not run them.

Previdian placed the bug on its own known-exploited-vulnerabilities list, while CISA has not added it to its KEV catalog. Hunter Strategy said the nine hours between disclosure and active exploitation leave no time for a typical patch cycle, and that patching does not remove access an attacker obtained before the update. Hunter Strategy said key-only accounts represent the real exposure, opening paths to deployment credentials, application secrets and connected infrastructure.

Ryan Dewhurst said attackers are moving faster with AI help and called this vulnerability particularly trivial to exploit. Previdian warned that proof-of-concept exploits on GitHub remain unverified and could contain malware.

OpenSSH 10.6p2 blocks the bypass by rejecting stored password hashes that are too short to be valid. Checkpoint said the use of SHA256 or SHA512 matters because sshd borrows the target account’s salt, and the attack fails without it. Checkpoint said the target account must be active instead of simply holding a hash, and that root accounts are safe under the default PermitRootLogin prohibit password setting even though reachable accounts with doas or sudo rights can still reach root. Ars Technica reported that exploitation requires at least one user account with a password hashed using SHA256 or SHA512.