Lightweight Linux distros vulnerable to *sshole password bypass

A bug dubbed "*sshole" lets attackers log into passwordless accounts on musl-based Linux distributions using a password between 257 and 1024 characters long.

Alpine Linux's cloud images are especially exposed because their default "alpine" user has no password and can become root without one.

OpenSSH has released update 10.6p2 to fix the flaw, tracked as CVE-2026-123158 with a CVSS score of 8.1, and administrators must restart sshd after upgrading.

A researcher has unearthed a curious bug in some Linux distributions that lets accounts which shouldn’t take passwords at all accept one, provided it is between 257 and 1024 characters long.

The edge case involves authentication through OpenSSH, the open source secure shell remote access software, and affects lightweight Linux distributions built on musl, an alternative to the standard C library most distributions use.

Security researcher Özgün Kültekin of Wakefield named the bug “*sshole”, the leading asterisk a nod to the character at the heart of the easily exploited flaw.

Kültekin found that on distributions built around musl, such as Alpine, which is popular for Docker containers and cloud servers, an attacker could log in to a passwordless account by supplying an arbitrary password between 257 and 1024 characters long.

Such logins succeed as long as the OpenSSH server daemon, sshd, is not set to use Pluggable Authentication Modules (PAM), which is the default for Alpine’s standard OpenSSH package.

The attacker needs the name of a passwordless account, and the machine must also have at least one other account with a real password.

Passwordless accounts store a single asterisk (*) where a scrambled fingerprint, or hash, of a password would normally go.

When someone types in a password longer than 256 characters, the hashing function in musl gives up and returns an asterisk as its error message.

Comparing the two, sshd sees an asterisk on both sides and treats it as the correct password.

“If you operate a Linux system that uses musl libc without PAM (Alpine Linux is one example) then stop reading and set PasswordAuthentication=no or disable SSH for these systems IMMEDIATELY,” Damien Miller, OpenSSH developer, said .

Root, the all-powerful superuser account, has been passwordless on Alpine since version 3.16, but OpenSSH’s default settings refuse password logins for root.

Alpine’s official cloud images are more exposed, however, because their default “alpine” user has no password and can become root without one.

On those systems, once any account on the machine has a password, an attacker can log in as the alpine user and take over the server.

Alpine containers are only at risk if they run sshd, which most do not.

The vulnerability developed in stages and was properly introduced in 2016.

Since that year, a fix for the CVE-2016-6210 vulnerability has made sshd’s dummy password check for accounts with no real hash use the details of a real account, so that attackers timing its responses can’t tell which usernames exist.

Verint researcher Eddie Harari found that flaw by timing how long sshd took to reject very long passwords .

The irony is that the fix for a timing flaw found with long passwords set up the current long-password authentication bypass.

The bug has been assigned CVE-2026-123158, rated 8.1 out of 10 under the Common Vulnerability Scoring System (CVSS) 3.1.

OpenSSH has issued an update, 10.6p2, and administrators must restart sshd after upgrading; setting PasswordAuthentication to “no” also closes the vulnerability.

Alpine Linux has published patched packages for every branch back to version 3.16.

Systems built with Buildroot or Yocto can also be affected, as can OpenWrt devices that have replaced the default Dropbear SSH server with OpenSSH.

Kültekin discovered the flaw with the help of AI agent swarms, building sshd in every combination of glibc, musl, PAM and no PAM, then throwing 17,600 unusual logins at them.