A password between 257 and 1,024 bytes long can open an account over SSH that should not accept passwords. The flaw, dubbed sshole and registered as CVE-2026-123158, affects certain OpenSSH configurations on Linux that use the musl library without PAM. OpenSSH and Alpine Linux released fixes on November 5.
Simply running Linux or Alpine is not enough to be exposed: several requirements must coincide, including that the server accepts password authentication and that there are accounts with certain fields and hashes. But a single connection may be enough to exploit it. Previdian reported eight attempts from the same IP address and confirmed that one gained administrator access on a decoy server.
A string comparison that ends in access
SSH lets administrators manage machines over a network; OpenSSH is a common implementation of the protocol, and sshd is its server. On Linux, /etc/shadow contains the data used to verify passwords. For some accounts configured to authenticate only with keys, the password field appears as an asterisk: *. That marker should prevent access using an ordinary password, not authorize it.
The flaw occurs when sshd tries to check a password for an account whose field does not contain a usable hash. In builds without PAM, OpenSSH uses the system library's crypt() function to process the attempt and compare it with the stored value. If the account field does not have a salt that allows this check, the server borrows the salt from another account.
In musl, crypt() returns * as an error indicator if the password exceeds 256 bytes. This result matches the character stored in accounts without a password. The comparison ends up treating two values that do not represent a valid password as equal, and authentication is accepted. The exploitable range described by Alpine and OpenSSH is 257 to 1,024 bytes.
Alpine summarizes the practical requirements as follows: the attacker needs to know the name of an account with * in the password field, and the machine must have at least one other local account with a hash beginning with $5$ or $6$, corresponding to SHA-256 and SHA-512. A single account with a password is enough to potentially expose accounts without one, provided the other conditions are also met.
“An attacker who can reach your SSH port can log in without knowing any password. It takes one connection, works every time, and needs no retries.”
— Alpine Linux team
Alpine meets the requirements, but it is not the only system to check
The case confirmed by Alpine includes machines running its openssh-server package, built without PAM, or openssh-server-pam with UsePAM no. Password authentication must be enabled; Alpine says OpenSSH enables it by default unless the administrator changes the configuration. There must also be an account whose field is * and another local account with a $5$ or $6$ hash.
Accounts that may have the asterisk include root, users created to authenticate only with keys, and accounts sourced from directory services through musl-nscd, such as nslcd, winbind, or sssd. In Alpine, the root account has been root:* in the base image since approximately version 3.16. However, the default PermitRootLogin prohibit-password setting protects it from direct password access. That barrier does not eliminate the risk if another account that can log in gains root privileges, for example through doas.
Alpine considers all the versions it checked affected: 3.21 through 3.24 and edge, as well as the older 3.16 through 3.20 branches, which no longer receive regular updates. The vulnerability is not necessarily limited to that distribution: other OpenSSH builds on musl without PAM may meet the same conditions. Help Net Security lists OpenWrt, Buildroot, and Yocto among the systems worth checking.
According to Alpine's advisory, machines with PasswordAuthentication no, those using PAM with UsePAM yes, those without password hashes in $ format, and locked accounts whose field begins with ! are not affected. Neither are Docker or other containers that do not run sshd, nor cloud images configured through cloud-init, which sets PasswordAuthentication no.
Red Hat stated that its products are not affected: its OpenSSH builds link against glibc and use PAM by default. Help Net Security also identifies Debian, Ubuntu, and Fedora, which use glibc, as outside the scenario, along with configurations that use PAM, Dropbear, and OpenBSD. The decisive factor is not simply the distribution, but the combination of library, authentication method, and accounts.
tiny-cloud images can go from safe to vulnerable
Alpine identified a specific risk in its official tiny-cloud images, distributed as qcow2, VHD, and AMI artifacts. Images for versions 3.18.11 through 3.24.3 include an alpine user with a password field of * and passwordless doas access. They are safe on first boot, but can become exploitable as soon as a $6$ hash appears on the machine.
This can happen, for example, if an administrator sets a password from the console or if user data adds an account with hashed_passwd. If an attacker logs in as alpine, they can use doas to become root. Images built with Alpine 3.21.10, 3.22.8, 3.23.8, 3.24.4, and later include the fixed package; images from earlier point releases require updating OpenSSH or disabling password authentication on every instance that is still running.
Alpine clarifies that users of cloud images configured by cloud-init are outside the described scenario because that tool writes PasswordAuthentication no. The difference between a freshly booted image and a machine modified afterward is important: adding a password or an account can satisfy one of the conditions that was previously missing.
A flaw born of separate decisions
Researcher Özgün Kültekin of Wakefield reported the issue. The technical explanation links changes introduced at different times. In 2012, musl limited the length of passwords it processes to prevent denial-of-service attacks; for an excessively long input, crypt() returns the error asterisk. In 2016, OpenSSH changed how it checks accounts without a usable hash to make it harder for an attacker to infer which usernames existed by measuring response times.
Alpine also adjusted its administrator account configuration in 2022 to allow access using SSH keys. Each change addressed a different problem or need. The interaction between musl's error handling and OpenSSH's checking mechanism caused the symbol used to signal an error to match the field in accounts without a password.
Help Net Security adds that Kültekin tested different builds of sshd and ran about 17,600 unusual login tests. According to the outlet, only the build with musl and without PAM allowed access that should have been rejected. Kültekin said he used AI agents for the work, although the available information does not detail which parts of the tests each one ran.
OpenSSH said in the 10.6p2 release notes that it considers the root cause to be outside sshd, but that the issue can be exploited through the server and mitigated there. The update includes a fix in OpenSSH. Alpine, for its part, distributed fixed packages for its branches.
Previdian confirmed one access; initial reports differed
The vulnerability became public on November 5 along with the fixes. On November 6, Help Net Security reported that Previdian had observed activity on its sensors: eight attempts, all from a single Japanese IP address and captured by one sensor. The company confirmed that one of them gained root access on a honeypot running genuine Alpine Linux and OpenSSH.
Previdian founder Ryan Dewhurst told Help Net Security that the first observed attempt arrived less than nine hours after the CVE was published. According to his description, the source address 89.116.89[.]18 sent excessively long passwords and ran reconnaissance commands such as id, uname, and hostname in non-interactive SSH sessions. Previdian added the flaw to its own list of exploited vulnerabilities. CISA had not added it to its KEV catalog at that time.
SecurityWeek's coverage published the same day described an earlier situation: it said there had not yet been reports of exploitation and anticipated that scanning could begin within hours. Fredrik Almroth, co-founder of Detectify and principal security researcher, estimated that Shodan showed around 22 million systems with SSH open on port 22, though he warned that the actual figure was higher and that only some would be running Alpine. Jake Knott, WatchTowr's head of threat intelligence, expected brute-force attempts before the weekend. Help Net Security's later report provided confirmation of the attempts and access to the decoy.
The OpenSSH notes explain the speed of the release. The team said it has received numerous security bug reports, several found by AI models or with their help, and has seen cases where another researcher independently discovers a flaw first identified by AI tools. For that reason, it announced that it will publish releases more frequently for now so fixes arrive sooner, rather than bundling them until the next planned release.
Updating is not enough if the old process is still running
OpenSSH released version 10.6p2 on November 5, 2026. The fix prevents the bypass in sshd; the notes also include other changes, including enabling the post-quantum hybrid signature algorithm ssh-mldsa44-ed25519 as an allowed algorithm for CA signatures and fixing a sub-second CPU spin when ChannelTimeout was used.
Alpine released fixed packages for branches from 3.16 through edge. The versions specified in its advisory are: edge, 10.6_p2-r0; 3.24, 10.3_p1-r2; 3.23, 10.2_p1-r1; 3.22, 10.0_p1-r11; 3.21, 9.9_p2-r1; 3.20, 9.7_p1-r6; 3.19, 9.6_p1-r3; 3.18, 9.3_p2-r4; 3.17, 9.1_p1-r7; and 3.16, 9.0_p1-r6. Branches 3.21 and earlier include versions that no longer receive regular support; Alpine nevertheless released fixed packages as far back as 3.16. Version 3.21 reached end of support on November 1, 2026.
The operational step Alpine emphasizes is restarting sshd after updating: installing the package does not replace the process that is already running. If applying the patch is not possible, the advisory recommends disabling PasswordAuthentication and restarting the service. Before doing so, check that key-based access works and keep the current session open until a new connection has been tested, to avoid losing administrative access.
To look for signs of intrusion, Alpine recommends checking /var/log/messages for sshd lines containing “Accepted password for” for accounts without passwords, such as alpine, root, or users with key-only access. It also advises reviewing doas usage, recently created accounts, files, and authorized keys on exposed machines. If a login cannot be ruled out, Alpine says to treat the system as compromised.
Help Net Security also reported that proof-of-concept exploits were circulating on GitHub, but Previdian warned that they were unverified and could contain malware. For administrators, the immediate action recommended by Alpine and OpenSSH remains straightforward: update the package and restart the daemon, or disable password access and restart it while waiting for the update.
Sources: Xataka, Alpine Linux, OpenSSH, Red Hat, Help Net Security, SecurityWeek
