Less than nine hours after the CVE-2026-123158 vulnerability was published, Previdian detected the first exploitation attempt. The firm confirmed that one of the attacks gained root access on a honeypot running Alpine Linux and OpenSSH. The flaw, dubbed SSHole, allows password authentication to be bypassed in certain Linux configurations based on musl.
Previdian counted eight attempts, all originating from the IP address 89.116.89[.]18, geolocated to Japan and detected by the same sensor. According to Ryan Dewhurst, the company’s founder and CEO, the attacker sent excessively long passwords and, after entering non-interactive SSH sessions, ran reconnaissance commands such as id, uname and hostname.
The vulnerability is identified as CVE-2026-123158 and has a CVSS score of 8.1. It affects OpenSSH on Linux systems that use the musl C library and do not verify passwords through PAM; Alpine Linux includes this combination in its default OpenSSH server configuration. The issue was fixed in OpenSSH 10.6p2.
A chain of conditions allows passwordless access
SSHole does not open every password-protected account. For the attack to work, the machine must have at least one account whose password field contains an asterisk (*), used for accounts without a usable password, and another local account with a password hash. Password access must also be enabled, and the specific build and authentication conditions must be met.
The attacker, who needs neither credentials nor SSH keys, sends a password between 257 and 1,024 bytes long. In the affected configuration, this attempt triggers a failure while calculating the hash. The musl library then returns an asterisk, which matches the stored value for the account without a password. OpenSSH interprets the match as valid authentication.
Alpine explains that the presence of just one local user with a hash beginning with $5$ or $6$ can expose accounts without passwords. By contrast, locked accounts whose field begins with ! cannot log in with a password or key, and are not the target described in the advisory.
The access gained retains the permissions of the compromised account. Safe Security warned that the consequences depend on those privileges and that, in addition to allowing an unauthorized SSH connection, the intrusion could expose deployment credentials, application secrets and connected infrastructure, potentially enabling lateral movement or service disruption.
The origins trace back to a 2016 OpenSSH change
Özgün Kültekin, a Wakefield researcher who discovered the flaw, traced its origins to an OpenSSH change introduced in 2016 to fix CVE-2016-6210, an issue that made it possible to determine which usernames existed on a server. The change made sshd calculate a hash even when an account had no usable hash, using the salt from another account.
The second piece of the puzzle is in musl. According to the analysis published by Alpine, its crypt() function returns * when given a key longer than 256 bytes. The same character fills the password field for accounts that do not have a password configured. When comparing the calculated result with the stored value, the server may accept the login.
Help Net Security reports that Kültekin tested sshd builds with different combinations and made around 17,600 unusual login attempts. Only the build with musl and no PAM accepted logins it should have rejected. The researcher also attributed some of that work to automated agents: “oh did i say “i”? sorry. i had agent swarms. a lot of them. let’s not get into it”.
Alpine says the issue affects versions of its distribution from 3.16 through 3.24, as well as edge, provided the other conditions are met. The root account has had * in the base image since approximately Alpine 3.16, but the default OpenSSH setting, PermitRootLogin prohibit-password, prevents direct root access using a password. The risk can return if direct access is allowed or if an accessible account can escalate privileges with doas.
Tiny-cloud images can turn access into root
Alpine’s advisory identifies a specific case in its official tiny-cloud images: the qcow2, VHD and AMI artifacts for versions 3.18.11 through 3.24.3 include an alpine user with no password and passwordless access to doas. They are safe on first boot, but become vulnerable when a $6$ hash exists on the machine—for example, if an administrator sets a console password or user data creates an account with hashed_passwd.
In that situation, an attacker could log in as alpine and use doas to become root. Alpine clarifies that images built with versions 3.21.10, 3.22.8, 3.23.8, 3.24.4 and later include the fixed package. Instances already running must update OpenSSH or disable password authentication.
The flaw does not affect glibc-based systems such as Debian, Ubuntu and Fedora, or systems that use PAM to check passwords. It also does not affect Dropbear or systems that do not run sshd in their containers. Red Hat says its products are not affected: its OpenSSH builds use glibc and PAM by default.
Previdian added SSHole to its own list of exploited vulnerabilities. CISA has not added it to its KEV catalog, according to Help Net Security. Dewhurst argued that attackers are speeding up their timelines with the help of artificial intelligence and described this flaw as particularly easy to exploit. However, the observations published by Previdian are limited to the eight attempts from a single address.
Updating is not enough if sshd is still running
The fix is available in OpenSSH 10.6p2. Alpine published updated packages for its branches and specifies that installing the package does not replace the sshd process that is already running: the service must be restarted. For its stable branches, the fixed OpenSSH versions are 10.3_p1-r2 in Alpine 3.24, 10.2_p1-r1 in 3.23, 10.0_p1-r11 in 3.22 and 9.9_p2-r1 in 3.21. Packages are also available for earlier branches: 9.7_p1-r6 in 3.20, 9.6_p1-r3 in 3.19, 9.3_p2-r4 in 3.18, 9.1_p1-r7 in 3.17 and 9.0_p1-r6 in 3.16. The edge branch includes 10.6_p2-r0.
Alpine recommends updating OpenSSH and restarting the service. If it is not yet possible to apply the update, it advises disabling password authentication in the SSH configuration and restarting sshd. The OpenSSH team, through Damien Miller, asked users running Linux with musl and no PAM to immediately disable password authentication or SSH on those systems.
To look for signs of access, Alpine recommends checking /var/log/messages for sshd lines containing “Accepted password for” associated with accounts that should not accept passwords, such as alpine, root or users who should only log in with a key. It also advises checking doas usage, recently created accounts, files and authorized keys. If a login cannot be ruled out, it recommends treating the machine as compromised.
Help Net Security’s analysis mentions proof-of-concept exploits published on GitHub, but Previdian warns that they are unverified and could contain malware. Meanwhile, Alpine published fixed packages even for older versions: branch 3.21 reached end of support on November 1, 2026, but the team says it published fixes for every version down to 3.16.
Sources: The Hacker News, Help Net Security, teapawt, Alpine Linux, Red Hat Customer Portal
