OpenSSH 10.6p2 closes Alpine Linux SSH authentication bypass

OpenSSH has released version 10.6p2 to address a critical authentication bypass that can affect Alpine Linux servers using the standard openssh-server package. Under a specific set of conditions, an attacker with network access and the name of a passwordless account can authenticate by submitting a password between 257 and 1,024 bytes long.

Alpine has published fixed packages for supported releases and also supplied fixes for branches from 3.16 to 3.21 that have reached end of support. Point releases 3.21.10, 3.22.8, 3.23.8 and 3.24.4 already contain the corrected package. OpenSSH said no CVE identifier had been assigned and no exploitation had been reported at the time of publication.

Which Alpine systems are exposed

The issue requires several conditions at once. The machine must run Alpine's non-PAM openssh-server, or openssh-server-pam with UsePAM no; PasswordAuthentication must be enabled; a local account must have * as its password field; and another local account must have a password hash beginning with $5$ or $6$.

Alpine's standard OpenSSH server is built without PAM, while password authentication is enabled by default. Passwordless accounts can include key-only users created without a password, directory-service users lacking a shadow entry, the alpine account in official tiny-cloud images, and root, which has shipped as root:* in the base image since about Alpine 3.16.

Root is normally protected by the default PermitRootLogin prohibit-password setting. That control does not prevent privilege escalation when an exposed account can use a tool such as doas. Tiny-cloud images from 3.18.11 through 3.24.3 give the alpine user passwordless doas, creating a path to root after another account receives a compatible password hash.

Why an overlong password is accepted

Without PAM, sshd hashes a password attempt through the C library function crypt() and compares the output with the stored password field. For an account whose field is only *, sshd borrows the salt from another account with a usable hash because the short field cannot contain one.

With $5$ and $6$ hashes, musl's crypt() rejects passwords longer than 256 bytes and returns *. That error value then matches the passwordless account's stored field. OpenSSH limits submitted passwords to 1,024 bytes, defining the affected range. Version 10.6p2 changes sshd so that a stored field shorter than four characters cannot produce a successful match.

The exposure also illustrates the broader Linux attack surface mapped in Linux rootkits, router zero-days and AI attacks, where security teams must account for privilege paths that extend beyond the initial access mechanism. OpenWrt, Buildroot and Yocto installations using musl merit review as well, although OpenWrt uses Dropbear by default and Dropbear is not affected.

Update, restart and review access

On Alpine, administrators should run apk upgrade -U -a and then restart the daemon with rc-service sshd restart; the package upgrade alone does not restart a running sshd process. Self-built deployments should move to OpenSSH 10.6p2.

Where an update cannot be applied immediately, setting PasswordAuthentication no prevents the attack. Administrators should first confirm that SSH key access works and retain the existing session until a new login succeeds, validate the configuration with sshd -t, restart sshd, and verify the effective setting with sshd -T | grep -i passwordauthentication.

Teams should inspect /var/log/messages for accepted password logins to accounts that have no password and review doas activity, new users, files and authorized keys on exposed hosts. If a login cannot be ruled out, the advisory says the machine should be treated as compromised. The practical priority is to patch and restart sshd, disable password authentication where needed, and validate access controls on any affected Alpine server.