On November 5, 2026, Alpine Linux disclosed a vulnerability that, under certain conditions, lets an attacker log in over SSH without knowing the password, and released fixes. On the same day, OpenSSH published version 10.6p2, which includes a mitigation for the issue. Even accounts you believe are used only with public key authentication can be exposed if the SSH server (sshd) is set to accept password authentication. Alpine's official advisory urges administrators to check the server's actual authentication settings, not just their account management policies.
The key to understanding this issue is the difference between disabling an account's password and disabling password authentication on the SSH server. The former changes the credentials stored for the account. The latter uses PasswordAuthentication no to make sshd itself refuse password authentication. This distinction matters both in the cloud scenario where setting a password for a different user creates the conditions for the vulnerability, and in how you verify the safety of existing servers.
How the "*" That Rejects Passwords Ends Up Letting Logins Through
When sshd runs without PAM (Pluggable Authentication Modules), it processes the submitted password with the crypt() function and compares the return value with the value stored for the account. Normally, what is stored is not the password itself but a hash computed for verification. However, to prohibit password logins, some accounts store the special string * instead of a valid hash. This * is not a symbol for a public key; it is a value that makes password authentication fail.
According to Alpine's explanation of the cause, when the stored value is short, sshd borrows a "salt" from the password hash of another local account. A salt is a value added when hashing a password. However, when more than 256 bytes of input are passed to the crypt() function in musl, a standard C library, it returns * to indicate an error. Because this return value matches the * stored for the target account, the password check is wrongly judged to have succeeded.
In other words, the cause is that the value meant to reject authentication and the value indicating a calculation error are the same string. Alpine states that the input lengths usable in an attack are 257 to 1024 bytes, specified in bytes rather than characters. The attacker does not need to crack a password or steal a private key; they can pass authentication by exploiting the error value returned by crypt().
A technical write-up by the discoverer, Wakefield, explains how the vulnerability arose from a combination of changes made to several pieces of software. In 2012, musl changed how it reports errors and introduced an input length limit. In 2016, OpenSSH added a process to obtain the salt from another account, to prevent information from leaking through differences in processing time. Then, in 2022, Alpine reportedly changed the stored value for the root account to enable public key login. Together, these changes created the conditions under which this authentication bypass works.
In his own research report, Wakefield explains that the problem has existed since 2016, when OpenSSH 7.3p1 was released. The vulnerability therefore did not first arise from Alpine's 2022 change. Meanwhile, the OpenSSH release notes state that the root cause lies outside sshd, but that because the problem can be exploited through sshd, a mitigation was built into version 10.6p2.
Accounts Meant for Public Key Authentication Only Can Still Be Breached
For this vulnerability to work, the attacker must not only be able to reach the SSH server, but several conditions about the authentication method and the account's state must also be met. Alpine's standard openssh-server does not use PAM, and a PAM-enabled build meets the same condition if UsePAM no is set. In addition, PasswordAuthentication yes must be enabled, the stored value for the target login account must be exactly *, and another local account must have a password hash beginning with $5$ or $6$. Checking each of these individually is not enough; whether you are affected must be judged from the combination of conditions.
The table below summarizes the affected and unaffected conditions given in Alpine's official advisory. It also draws on Wakefield's research and OpenSSH's explanation of its mitigation, but it is not the result of independent reproduction testing and does not uniformly determine the impact on other Linux distributions.
| State to check | Relation to this bypass | Note when judging |
|---|---|---|
| sshd is not running | Not affected | Not every container using Alpine is affected |
PasswordAuthentication no |
Blocks this authentication path | Different from disabling an account's password |
PAM-enabled build with UsePAM yes |
Not affected per the official advisory | You need to check the effective configuration, not just whether the PAM build is installed |
PasswordAuthentication yes, using the standard build or a PAM build with UsePAM no |
Part of the conditions | This setting alone does not make a system vulnerable |
The stored value of the login-capable target account is exactly * |
Part of the conditions | Different from !. According to Alpine, ! also rejects public key login |
Another local account has a hash beginning with $5$ or $6$ |
Part of the conditions | Adding a password later changes the conditions for the whole server |
| On a reachable SSH server, the vulnerable authentication path and account conditions are all met | Bypass may be possible | Judge by the combination, not by individual conditions |
It is worth noting that a policy of using only public key authentication for accounts is a different thing from disabling password authentication on the SSH server with PasswordAuthentication no. The actual impact depends on the combination of whether musl and PAM are used, sshd's authentication settings, the stored value of the target account, and password hashes present on other accounts. For the root account, the default PermitRootLogin prohibit-password prevents password authentication, but a change to PermitRootLogin yes can make it a target. And even when direct root login is prohibited, the route of breaking into a regular user and then escalating privileges with doas must be considered separately.
That said, not every system that uses musl is affected. Ars Technica's report points out that OpenWrt's default SSH server is Dropbear, not OpenSSH, and that no impact on Buildroot or Yocto has been confirmed. The number of devices using musl cannot be equated with the number of vulnerable devices. Moreover, because simply adding a password for another user on the same server can change whether the conditions are met, you need to check the authentication settings and operating state of the whole server, not just individual accounts.
Cloud Environments That Start Out Safe Can Become Vulnerable After Operation Begins
What makes this issue especially troublesome is that a cloud environment that was safe at first can become vulnerable through configuration changes made during operation. The images Alpine officially lists are the qcow2, VHD, and AMI images using tiny-cloud, versions 3.18.11 through 3.24.3. In these images, the stored password value for the alpine user was set to *. This user is also granted the ability to use doas without a password.
Alpine explains that these images are in a safe state at first boot. However, the situation changes if an administrator sets a password for another account from the console, or specifies hashed_passwd in the user-data that passes configuration at boot. When a password hash beginning with $6$ is added to the server, the conditions are met for sshd to obtain a salt from another account, and the existing alpine user can become a target of the bypass.
For example, suppose you distribute a public key and start running a cloud instance, then later add a password to secure an alternative way to log in. That action changes the security not only of the account to which you added the password but also of the alpine user, whose stored value was originally *. And because this user can use doas without a password, an attacker who gets in can escalate to root privileges. This differs from logging in directly as root: it is an attack in two stages, breaking into a regular user and then escalating privileges.
Therefore, to judge the safety of a cloud environment, you must check not only the settings at image creation but also the passwords added after boot and the current sshd configuration. Also, even if the distributor publishes fixed images, instances that are already running are not fixed automatically. For existing environments, you need to update the installed packages and also apply the fix to the running sshd.
Check Whether You're Fixed by Alpine Branch and Revision Number
In its official advisory of November 5, 2026, Alpine published the fixed package numbers for each branch. In upstream OpenSSH the fixed version is 10.6p2, but for Alpine's stable releases, packages with the fix backported to each existing version are provided. Rather than comparing only the OpenSSH version number, you therefore need to check the combination of the Alpine branch you use and the package revision number (the part after -r).
| Distributor / branch | Fixed version per official sources |
|---|---|
| OpenSSH upstream | 10.6p2 (released November 5, 2026) |
| Alpine edge | 10.6_p2-r0 |
| Alpine 3.24 | 10.3_p1-r2 |
| Alpine 3.23 | 10.2_p1-r1 |
| Alpine 3.22 | 10.0_p1-r11 |
| Alpine 3.21 | 9.9_p2-r1 |
| Alpine 3.20 | 9.7_p1-r6 |
| Alpine 3.19 | 9.6_p1-r3 |
| Alpine 3.18 | 9.3_p2-r4 |
| Alpine 3.17 | 9.1_p1-r7 |
| Alpine 3.16 | 9.0_p1-r6 |
Alpine 3.21.10, 3.22.8, 3.23.8, and 3.24.4 include this fix. For existing environments, the official guidance is to update packages with apk upgrade -U -a. However, updating the packages does not necessarily apply the fix to an sshd that is already running. After updating, you need to restart the SSH server by running rc-service sshd restart.
If you cannot update packages right away, the suggested workaround is to set PasswordAuthentication no and restart sshd. To avoid locking yourself out through the configuration change, however, it is advisable to confirm beforehand that you can connect with public key authentication, and to test a new connection while keeping your existing one open. You can use sshd -t to check the syntax of the configuration and sshd -T to check the effective settings. Note also that versions before Alpine 3.19 have no built-in mechanism for loading additional configuration files by default, so do not assume the mitigation is active just because you placed a configuration file; reflect the change in the configuration that is actually loaded.
Beyond applying the fix, it is also important to investigate whether any unauthorized logins occurred in the past. Alpine advises checking /var/log/messages for successful authentication records of the form Accepted password for against accounts whose stored password value is *. If password authentication succeeded on an account that was supposed to be public-key-only, unauthorized access should be suspected. You should also check doas execution history, the creation of new users, and changes to files and authorized_keys.
However, not finding suspicious logs does not prove that no intrusion occurred. Alpine asks that, if the possibility of compromise cannot be ruled out, the system be treated as already compromised. Responding to this vulnerability requires three separate steps: installing the fixed packages, applying the fix to the running sshd, and investigating past unauthorized access. Rather than relying solely on a public-key-only policy, properly controlling password authentication on the SSH server side is also key to preventing similar authentication bypasses.