Alpine Linux fixes openssh-server flaw that allowed password-less login

What was discovered

The Alpine Linux team published a security advisory on November 5, 2026, describing a bypass in openssh-server's password authentication. An attacker who can reach the SSH port can log in without knowing any password. A single connection is enough: there's no need to repeat attempts or force anything.

The bug was fixed in OpenSSH 10.6p2, but as of the advisory's publication no CVE identifier had been assigned. The report came from Özgün Kültekin, of Wakefield, with analysis by Timo Teräs and a fix by Damien Miller and Darren Tucker, of the OpenSSH project. Natanael Copa packaged and published the fixed versions for Alpine.

How the attack works

The problem lies in how sshd without PAM validates passwords. It uses the libc crypt() function to hash the password attempt and compares the result with the field stored in /etc/shadow. When that field is too short to contain a salt (the random prefix of the hash), sshd borrows the salt from another account on the system.

musl, the libc used by Alpine, has a specific behavior: its crypt() returns the string * as an error indicator when the submitted password exceeds 256 bytes. The problem is that * is exactly what the password field contains for accounts with no password set (common for key-only users). The attacker sends a password between 257 and 1024 bytes long, the error hash matches the * field, and the login is accepted.

For the attack to work, two conditions must coexist on the machine:

• An account whose password field is * exists (a password-less account, normal for users configured with SSH key only).
• At least one other account with a $5$ or $6$ password hash exists on the system.

A single user with a password set is enough to make every password-less account reachable by anyone who knows its name.

Who is exposed

Alpine confirms the bug in all supported versions (3.21 to 3.24 and edge) as well as in those that have already left regular support (3.16 to 3.20). But not every server running Alpine is vulnerable: it depends on a specific combination of configuration.

Docker containers that don't run sshd inside the container are not affected, nor are cloud images configured via cloud-init, which already write PasswordAuthentication no by default.

The case of root deserves separate attention: since around version 3.16, Alpine's base image has shipped with root:* by default. OpenSSH's default protection, PermitRootLogin prohibit-password, blocks this specific vector for root, unless someone has turned on PermitRootLogin yes, or another exploitable account can become root via doas.

Tiny-cloud cloud images are also on the list

Official tiny-cloud images (qcow2, VHD, and AMI artifacts) from versions 3.18.11 through 3.24.3 ship with an alpine user with a * password field and passwordless doas enabled. On first boot they are safe, because no $6$ hash exists yet on the machine.

They stop being safe as soon as any hash of this type appears, for example when an administrator sets a console password or when cloud-init's user-data creates a user with hashed_passwd. From that point on, an attacker gains a shell as alpine and uses doas to become root.

Images generated from versions 3.21.10, 3.22.8, 3.23.8, 3.24.4, and later already ship with the fixed package. Instances already running, built from earlier versions, need to be updated manually or have password authentication turned off.

How to fix it

Alpine's recommended fix is simple: update the package and restart the daemon. Updating alone is not enough, because the running sshd keeps running the old binary until it's restarted.

apk upgrade -U -a
rc-service sshd restart

The fixed versions by branch are:

Those who can't update right away have an immediate way out: turn off password authentication. Before running the commands, make sure SSH key login works and keep the current session open until you confirm the new access is enabled.

mkdir -p /etc/ssh/sshd_config.d
echo 'PasswordAuthentication no' > /etc/ssh/sshd_config.d/00-no-passwords.conf
sed -i.bak -e '1i PasswordAuthentication no' \
  -e 's/^\(\s*PasswordAuthentication[^y#]*\)yes/\1no/i' \
  /etc/ssh/sshd_config
sshd -t && rc-service sshd restart
sshd -T | grep -i passwordauthentication

The last command needs to print passwordauthentication no. To undo it, delete the file /etc/ssh/sshd_config.d/00-no-passwords.conf and restore /etc/ssh/sshd_config.bak over /etc/ssh/sshd_config.

How to know if the machine has already been attacked

Alpine advises checking /var/log/messages for sshd lines with Accepted password for accounts that have no password set, such as alpine, root, or any key-only user. It's also worth reviewing recent doas usage, users created in the last few days, modified files, and keys added to authorized_keys.

If it's not possible to rule out an unauthorized login on an exposed server, the recommendation is to treat the machine as compromised and follow whatever incident response process the team already has in place.

What changes for those who maintain infrastructure

The practical point here isn't just running apk upgrade: it's understanding that the combination of password-less accounts (common in key-only setups, which are well recommended as a best practice) with any password-set account on the same host is the trigger. Teams that use Alpine as a base image for servers with sshd active, including older tiny-cloud images, should audit today which machines have this combination, not just apply the patch and move on.

It's worth remembering that the patch covers Alpine's native openssh-server package; those using openssh-server-pam with UsePAM yes were never on the exploitation path, and switching to that mode is a permanent mitigation alternative, in addition to turning off PasswordAuthentication.