OpenSSH flaw on Alpine Linux allows passwordless logins

A flaw in OpenSSH lets attackers log into accounts on Alpine Linux servers and other musl-based systems without a password, in a single connection. OpenSSH and Alpine have fixed it: who is exposed and what to do.

On November 5, 2026, the OpenSSH project released version 10.6p2 with a critical fix: on Linux systems that use the musl C library and run without PAM (the module that handles authentication), an attacker who can reach the SSH port can log into certain accounts without knowing the password. Alpine Linux, the best-known musl-based distribution, published its advisory the same day: "It takes one connection, works every time, and needs no retries." The flaw was reported by Özgün Kültekin of the firm Wakefield and does not have a CVE identifier yet.

How it works

Accounts with no password, such as those that only log in with an SSH key, have an asterisk (*) in the /etc/shadow file. To check a password for one of those accounts, sshd borrows the salt (the random value stored with the hash) of another account, so at least one user with a real password must exist. When the submitted password is longer than 256 bytes, musl's hashing function fails and returns exactly an asterisk, which matches the account's field, and the server lets the attacker in. That is how the flaw allows passwordless logins with any text between 257 and 1,024 characters long. The researcher who found it estimates the problem has existed since 2016.

Who is exposed

According to Alpine's advisory, an Alpine server is vulnerable if all of these are true:

It uses the openssh-server package, which is built without PAM, or openssh-server-pam with UsePAM no.
PasswordAuthentication is enabled, which is the default.
It has an account with *: key-only users, users from a directory such as LDAP, root (since Alpine 3.16) or the alpine user in the official cloud images.
At least one account has a password hashed with SHA-256 or SHA-512.

Root is protected by the default PermitRootLogin prohibit-password setting, but anyone who gets in through another account with doas or sudo rights can still become an administrator. Affected Alpine releases range from 3.16 to 3.24. Docker containers that do not run sshd, glibc systems (Debian, Ubuntu, Red Hat) and devices that use Dropbear instead of OpenSSH, such as OpenWrt in its default setup, are not affected. The musl maintainer warns that any musl system running OpenSSH older than 10.6p2 without PAM is at risk, which can include embedded devices, such as routers or NAS units, that their manufacturer built on musl.

What to do

On Alpine, run apk upgrade -U -a and restart sshd (rc-service sshd restart): upgrading the package does not replace the service that is already running. Releases 3.21.10, 3.22.8, 3.23.8 and 3.24.4 include the fix, and Alpine published fixed packages going back to 3.16.
If you cannot update yet, disable password logins (PasswordAuthentication no) and restart sshd, after confirming that your SSH key works.
Look in /var/log/messages for "Accepted password" lines for accounts that have no password. If you cannot rule out a login, treat the server as compromised.
Ask the manufacturers of your routers, NAS units and embedded Linux devices whether they use musl with OpenSSH, and apply their updates.
Do not leave the SSH port open to the whole internet: restrict it with your firewall or a VPN.

How we help you

With Pronetsys server and infrastructure management we apply patches like this one, set SSH access to keys only and restrict it at the firewall. If you have Linux servers or devices and are not sure whether they are exposed, we can help you check them.