Alpine Linux issued a security advisory on November 5, 2026 for an SSH password-authentication bypass that can expose accounts with no password set. It tells administrators to update OpenSSH and restart the SSH server. Installing the package alone leaves the running daemon unchanged.
The risk includes accounts intended for key-only access when the server still permits password authentication. Exposure depends on the server's authentication configuration and stored account passwords. Alpine's advisory had no CVE identifier at publication; this article follows the published notices and does not reproduce the attack.
Which servers need attention
Alpine lists four conditions: PAM authentication is disabled, password authentication is enabled, an account has an asterisk as its password field, and at least one local account has a password hash beginning with $5$ or $6$. PAM is the authentication framework that some Linux services use to check logins.
The standard Alpine openssh-server package is built without PAM. The separate openssh-server-pam package is also exposed with UsePAM no, while UsePAM yes avoids this issue, according to the advisory. Containers that do not run an SSH server are outside the affected group. So are servers with PasswordAuthentication no.
An account intended for SSH keys therefore needs more than an unset password to be protected. Alpine says its default root account has the asterisk password field, but OpenSSH's default PermitRootLogin prohibit-password protects root from this path. Other login accounts can still be exposed, including ones allowed to become root through doas.
An error value passes the password check
Alpine's technical explanation traces the bypass to a collision between an error indicator and a stored account value. Without PAM, the SSH server uses the C library's crypt() function to hash a submitted password and compare it with the stored field. For a field too short to contain a salt, it borrows another account's salt.
In musl, the C library Alpine uses, crypt() returns an asterisk when a submitted password exceeds 256 bytes. That error value can match the asterisk stored for an account without a password. The comparison then accepts the login. Alpine says OpenSSH 10.6p2 avoids the problem in sshd; its stable-branch packages carry a patch for the same issue.
Apply the branch fix, then restart
Alpine has published patched packages back to release 3.16, including branches that no longer receive regular updates. Its stable packages carry a patch for the same problem, so a fixed installation need not report upstream version 10.6p2. Check the advisory's package table against the branch you run.
Alpine's update instructions are:
apk upgrade -U -a
rc-service sshd restart
If updating must wait, the advisory says disabling password authentication and restarting sshd closes this attack path. Verify that SSH key login works first, and keep the current session open while testing a new login. Alpine also recommends reviewing logs for accepted password logins to accounts without passwords.
Cloud operators should check existing instances as well as replacement images. Alpine says affected tiny-cloud images are safe on first boot but can become exploitable after a password hash is added to the machine. Its advisory identifies corrected images from 3.21.10, 3.22.8, 3.23.8 and 3.24.4 onward. Those new images do not update running instances: the next check is whether each exposed server has received its branch's fix and restarted the daemon.