OpenSSH published 10.6p2 on 5 November 2026 to close a password authentication bypass in sshd on musl-based Linux. On an exposed host an attacker logs in with one connection and no valid password.

What happened

When sshd is built without PAM, the default for Alpine's openssh-server package, it hashes the supplied password with the C library's crypt() call and compares the result to the account's stored field. An account with no password holds a single asterisk in that field.

musl refuses passwords longer than 256 bytes for the SHA-256 and SHA-512 hash types and returns an asterisk as its error value. That asterisk equals the stored asterisk, so the comparison passes. The working range is 257 to 1024 bytes, the second figure being sshd's own ceiling, and it succeeds on the first attempt with no retries.

OpenSSH rates the flaw critical and shipped a workaround the day after it was reported. No CVE identifier had been assigned when both advisories were published, and neither vendor has reported exploitation.

Who is affected

All four conditions must be true on the same machine:

• You run Alpine's openssh-server package, which is built without PAM, or openssh-server-pam with UsePAM set to no.
• PasswordAuthentication is still at its default of yes.
• An account exists with an asterisk in its password field: root on recent base images, a key-only user, or a directory-service user with no shadow entry.
• At least one other local account holds a $5$ or $6$ hash, which supplies the salt sshd borrows.

Alpine 3.16 through 3.24 and edge are in scope, along with the tiny-cloud images from 3.18.11 to 3.24.3 where the passwordless alpine user carries doas rights. The reporter also names OpenWrt, Buildroot and Yocto as musl systems to check, the last two being common in industrial and IoT firmware. glibc distributions, macOS and hosts that authenticate through PAM are not affected, nor are locked accounts using an exclamation mark in shadow.

What to do now

Update the package and restart sshd, because upgrading does not replace the daemon that is already running.

• Run apk upgrade -U -a, then rc-service sshd restart. Fixed packages sit in Alpine 3.21.10, 3.22.8, 3.23.8 and 3.24.4, and the project pushed builds back to 3.16.
• If you cannot patch today, set PasswordAuthentication to no. Confirm key login in a second session before you drop the current one, run sshd -t, then restart.
• Search /var/log/messages for accepted password lines against accounts that have none, and review doas use, new users and new authorized_keys entries on internet-facing hosts.

What this means for South African businesses

The blast radius is narrower than the critical rating suggests: a Windows and glibc estate is untouched. The real exposure sits in Alpine VMs and container hosts that run sshd, and in musl-based appliance firmware, which is precisely where a small business never looks. My read is that few SA SMEs are exposed directly, but the MSP or hosting provider running their site and mail on Alpine probably is, and one compromised management host reaches every customer on it. If you cannot say which of your Linux hosts run Alpine with password logins enabled, that inventory gap is the actual finding.

Source: Alpine Linux security advisory, 5 November 2026. The OpenSSH 10.6p2 release notes carry the same fix.