A Long Password Bypassed SSH Auth on Alpine Linux and OpenSSH Rushed an Emergency Fix

On some Alpine Linux servers, the password did not matter. An attacker who could reach the SSH port could log into certain accounts without knowing any password at all, in a single connection, every time. All it took was a password that was far too long.

Alpine disclosed the flaw on November 5, and OpenSSH pushed out version 10.6p2 as a critical workaround for musl-based systems running with PAM disabled. That combination is exactly how Alpine's default openssh-server package is built.

When an error looks like a password

The bug lives in the meeting point between OpenSSH and musl, the lightweight C library Alpine uses instead of glibc. Without PAM, sshd checks a password by hashing the attempt with the system's crypt() function and comparing the result to what is stored for the account.

Musl's crypt() signals an error by returning an asterisk when the input is oversized. An asterisk is also what sits in the password field of accounts that have no password, which is normal for accounts meant to log in only with keys. As Ars Technica explains, the error and the stored value matched, so sshd let the attacker in. OpenSSH considers the root cause to sit outside sshd, but it was sshd that made it exploitable.

Several things have to line up. The server must run sshd built without PAM, or the PAM build with UsePAM turned off. Password authentication must be enabled. There must be an account with an asterisk in its password field, and at least one other local account with a modern SHA-256 or SHA-512 hash.

Who is exposed

Alpine checked releases 3.16 through 3.24 plus edge and found them affected under those conditions. Its cloud images built with tiny-cloud are a sharp example: they ship an alpine user with no password and passwordless doas, so they become exploitable as soon as any SHA-512 hash exists on the box.

Plenty of systems are safe. Containers that do not run sshd are out of scope, as are servers with PasswordAuthentication set to no, PAM builds with UsePAM enabled, locked accounts, and glibc distributions. Other musl platforms such as OpenWrt, Buildroot and Yocto could be hit in principle under the same PAM-off setup.

The fix is out for every affected branch. Edge gets 10.6_p2-r0, Alpine 3.24 gets 10.3_p1-r2 and 3.23 gets 10.2_p1-r1, with patched packages going back to 3.16. Cloud images from 3.21.10, 3.22.8, 3.23.8 and 3.24.4 onward already include them.

Alpine's advisory stresses one trap above the rest: upgrading the package does not restart the running daemon, so a server stays vulnerable until sshd is restarted. Turning password authentication off and restarting also closes the hole.

That warning will sound familiar to Alpine operators. Only days ago, an exploit aimed at Alpine's own GitLab server showed that upgrading GitLab alone left the Ruby underneath still vulnerable. This time the gap sits in the SSH daemon that guards the machine itself.

The flaw was reported by Ozgun Kultekin of Wakefield, and Damien Miller and Darren Tucker of OpenSSH wrote the fix. Alpine said no CVE had been assigned when it published. Later tracking lists the bug as CVE-2026-123158, nicknamed SSHole, with a CVSS score of 8.1 in secondary reporting.

Some offers on this page may be paid placements or contain affiliate links.