OpenSSH flaw on Alpine Linux: SSH login without a password, and how to protect your server

On 5 November 2026 Alpine Linux published an urgent security advisory, and the OpenSSH team released version 10.6p2 the same day: anyone who can reach the SSH port on an affected Alpine server can log in to an account that has no password, without knowing any password. One connection is enough, and it works every time. The flaw affects every Alpine release from 3.16 to 3.24 and the edge branch, and Alpine is the base of many lightweight servers and container images. The flaw had no CVE number as of 5 November. This article covers how the flaw works, how to tell whether your server is affected, how to update it or protect it for now, and how to look for signs of an earlier login.

01What happened

Researcher Özgün Kültekin of Wakefield reported the flaw to the OpenSSH team, which shipped the fix in OpenSSH 10.6p2, and Alpine published patched packages for every release from 3.16 to 3.24 and for edge on the same day. The OpenSSH team says the root cause lies outside sshd, in the way the system checks passwords, but it is exploitable through sshd, so the team put a barrier inside sshd that blocks the exploit. According to OpenSSH, the flaw affects Linux systems that run on the musl library with sshd running without PAM, Alpine being the best known.

02How the flaw works

When sshd runs without PAM, it checks the password itself: it hashes the password the visitor sent with the crypt function, then compares the result with what is stored for the account in the /etc/shadow file. An account with no password has an asterisk * stored for it, which means no password can ever match it.

But hashing needs a “salt” read from the stored value, and the asterisk is too short to hold one, so sshd borrows the salt of another account that has a password. And when musl’s crypt function fails on certain inputs, it returns an asterisk * as an error marker. So sshd compares an asterisk with an asterisk, counts the password as correct, and the visitor is let into an account that was never meant to log in with a password.

That is why a single account with a password is enough to expose every account that has none. The root account has been stored with an asterisk by default in Alpine since around release 3.16, as have accounts created to log in with keys only.

03Is your server affected

An Alpine server is affected if all four conditions are true:

1. 01sshd without PAM: It runs the openssh-server package, built without PAM, or the openssh-server-pam package with UsePAM no.
2. 02Password login is on: The setting is PasswordAuthentication yes, which is the default.
3. 03An account whose password field is *: This is the default for root, and for users who log in with keys only.
4. 04At least one account has a password: That is, a stored value starting with $5$ or $6$.

These commands check the four conditions on your server, run as root:

# 1 and 2: the installed package, and sshd’s effective settingsapk info -e openssh-server openssh-server-pamsshd -T | grep -iE '^(usepam|passwordauthentication|permitrootlogin) '# 3: accounts whose password field is *awk -F: '$2 == "*" { print $1 }' /etc/shadow# 4: accounts that have a passwordawk -F: '$2 ~ /^\$[56]\$/ { print $1 }' /etc/shadow

If both of the last two commands print names, and password login is on without PAM, your server is affected.

What about root?

By default root is protected by the PermitRootLogin prohibit-password setting, which stops it from logging in with a password, unless you have changed it to PermitRootLogin yes. But that protection is not enough if another account can log in and then become root, for example through doas.

Alpine’s cloud images

Alpine’s official cloud images built with tiny-cloud, from release 3.18.11 to 3.24.3, come with a user called alpine that has no password and can become root through doas without a password. A server built from them is safe on first boot, but it becomes exposed as soon as any password in $6$ form appears on it, for example when someone sets a password for console login. The attacker then logs in as alpine and becomes root. Images built from releases 3.21.10, 3.22.8, 3.23.8, 3.24.4 and later carry the fix.

Not affected: containers that do not run sshd, which includes most Docker images built on Alpine; systems with PasswordAuthentication no, or openssh-server-pam with UsePAM yes; locked accounts whose field is ! rather than *; and cloud images set up with cloud-init, which writes PasswordAuthentication no.

04Update openssh and restart sshd

Take a backup first, then update the packages. Updating the package does not restart the running sshd, which keeps running the old code until you restart it:

# Update every package, then restart sshd so it runs the patched versionapk upgrade -U -arc-service sshd restart# The version installed nowapk info -v | grep '^openssh'

Compare the installed version with the patched version for your release, or a newer one:

Releases 3.16 to 3.20 are out of support, yet Alpine published patched packages for them because the flaw is so serious. Update them today, then plan your move to a supported release. And on any other system that runs on the musl library and runs sshd without PAM, update OpenSSH to 10.6p2.

ProblemI updated the package and the server is still exposed

FixThe running sshd has not been restarted, so it is still running the old code. Run rc-service sshd restart.

ProblemThe rc-service command does not exist

FixYou are most likely inside a container without OpenRC, where sshd runs directly. Update the image, then rebuild and restart the container.

ProblemThe installed version is older than the table’s

FixYour repositories point to another release, or apk has not refreshed its index. Run apk upgrade -U -a again and check the lines in /etc/apk/repositories.

ProblemI cannot update right now

FixTurn off password logins as in the next section, then update as soon as you can.

05If you cannot update now

Turn off password logins, since the flaw does not work without them. But first make sure your SSH key login works, and keep your current session open until you have tried a new login from another window, so you do not lock yourself out of the server. Then run as root:

# A drop-in settings file, then the same line at the top of the main file, keeping a copy as .bakmkdir -p /etc/ssh/sshd_config.decho 'PasswordAuthentication no' > /etc/ssh/sshd_config.d/00-no-passwords.confsed -i.bak -e '1i PasswordAuthentication no' \  -e 's/^\(\s*PasswordAuthentication[^y#]*\)yes/\1no/i' \  /etc/ssh/sshd_config# Check the settings, restart sshd, then read the effective valuesshd -t && rc-service sshd restartsshd -T | grep -i passwordauthentication

The last command should print passwordauthentication no. Releases 3.19 and later read the sshd_config.d folder by default, while older ones ignore it, which is why the sed command also adds the same line at the top of the main file.

06Has anyone got in?

The flaw is old in Alpine, and updating closes the door without evicting whoever came in before. So if your server was affected, search the logs for a password login to an account that has no password, such as root, alpine or any user who logs in with keys only:

# Password logins: compare the names with the list of accounts whose field is *grep 'sshd.*Accepted password for' /var/log/messages# Who used doas to become rootgrep doas /var/log/messages# The accounts that exist, and the key files with their change datescat /etc/passwdfind / -xdev -name authorized_keys -exec ls -l {} \; 2>/dev/null

• An Accepted password line for an account with no password: The clearest evidence the flaw was exploited, since that account never logs in with a password.
• doas use you did not make: A sign that whoever got in tried to become root.
• New users or keys: An account you did not create, an unknown key in an authorized_keys file, or new files in system folders.

07If you are an Illevante customer

• A CoreVPS server: CoreVPS’s ready operating system templates do not include Alpine, and none of them runs on the musl library, so a server created from one is not touched by this flaw. But if you run Alpine containers with sshd on it, apply what this article says to them.
• cPanel hosting: Our hosting servers run CloudLinux, which is not built on musl, so this flaw does not touch them and your site needs no action from you.
• If you need a hand: Our technical support team is with you around the clock if you need help checking your server or setting up key logins.

08The lesson: SSH keys instead of passwords

This flaw cannot touch a server everyone logs in to with keys. Three habits protect your server from its kind:

1. 01Keys only: Give everyone who logs in to the server an SSH key, then make PasswordAuthentication no a permanent setting rather than a temporary measure.
2. 02The SSH port is not for everyone: If the people who log in to your server work from known addresses, allow only those in the firewall, so an attacker never reaches the port at all.
3. 03Restart a service after updating it: Updating a package does not change the running service. Make restarting the service part of every security update.