OpenSSH released version 10.6p2 on November 5, 2026, with a workaround for a password-authentication bypass affecting some Linux systems that use musl. Alpine’s advisory describes a narrow set of conditions: an OpenSSH server without PAM, password authentication enabled, a target account whose password field contains *, and at least one other local account with a $5$ or $6$ password hash. Alpine administrators also need to restart the running sshd after installing the fix. (OpenSSH release notes; Alpine advisory)
What configuration does the bypass require?
For Alpine’s documented case, every listed condition must coincide. The server must run OpenSSH against musl with PAM disabled, either because the package was built without PAM or because UsePAM no is set. Its effective SSH configuration must also have PasswordAuthentication yes.
The target account’s password field must contain *, and another local account must have a $5$ or $6$ hash. With those prerequisites in place, a password input of 257 to 1,024 bytes can trigger the bypass. Alpine says an attacker who can reach the SSH service needs one connection and no retries. The issue therefore does not apply to every Linux or musl installation: Alpine says systems with PasswordAuthentication no, PAM-enabled OpenSSH, or accounts locked with ! are not affected by this issue. Containers that do not run sshd are also outside the described case.
A * in an account’s password field is not the same as disabling password authentication for the SSH server. The server setting still matters. Dropbear and other non-OpenSSH software are not affected by this OpenSSH issue, according to the musl advisory.
Which Alpine package revision fixes each branch?
Alpine published fixed openssh-server package revisions for edge and branches 3.16 through 3.24. Use the revision for the installed branch:
| Alpine branch | Fixed openssh-server revision |
| edge | 10.6_p2-r0 |
| 3.24 | 10.3_p1-r2 |
| 3.23 | 10.2_p1-r1 |
| 3.22 | 10.0_p1-r11 |
| 3.21 | 9.9_p2-r1 |
| 3.20 | 9.7_p1-r6 |
| 3.19 | 9.6_p1-r3 |
| 3.18 | 9.3_p2-r4 |
| 3.17 | 9.1_p1-r7 |
| 3.16 | 9.0_p1-r6 |
Alpine’s documented update command is apk upgrade -U -a, followed by a restart of the SSH service:
On Alpine, the package update does not replace the running sshd; restart the service to put the fix into effect.
Run rc-service sshd restart after the upgrade. If you cannot update yet, Alpine’s advisory recommends disabling password authentication and restarting sshd.
OpenSSH says the root cause is outside sshd, while its workaround is in the daemon. Rich Felker, the musl author, characterized the issue as erroneous use by the caller. Those are the projects’ stated positions. (OpenSSH; Rich Felker’s musl advisory)
When can Alpine tiny-cloud images be exposed?
Alpine’s official tiny-cloud artifacts from versions 3.18.11 through 3.24.3 include an alpine account with * in its password field and passwordless doas. Alpine says these images are safe on first boot. The conditions can arise later when a $6$ password hash exists on the machine, alongside the other prerequisites above. If an attacker then logs in as alpine, passwordless doas can provide a route to root. (Alpine advisory)
What should administrators check after updating?
Alpine recommends reviewing /var/log/messages for Accepted password entries for accounts that should have no password. Administrators should also review doas, user accounts, files, and authorized keys. Alpine advises treating a login as a compromise if it cannot be ruled out.
