OpenSSH on Alpine Linux: Password Bypass, What to Do

On 5 November 2026, OpenSSH and Alpine Linux released a fix for a flaw that lets someone log in over SSH without knowing the password on some Linux servers that use the musl C library and run without PAM, the typical Alpine setup. It is only exploitable when several conditions line up. Alpine Docker images that don't run an SSH server are not affected.

What we know

What it is: per Alpine's advisory, an attacker who can reach the SSH port can log in without knowing any password. The OpenSSH 10.6p2 release notes describe it as a password authentication bypass in sshd affecting some musl-based Linux systems running sshd without PAM support.
Where it comes from: per the OpenSSH notes, the root cause sits outside sshd (in the system library), but it is exploitable through sshd and is fixed there.
When it applies (all at once, per Alpine):

- the server uses the `openssh-server` package (no PAM) or `openssh-server-pam` with `UsePAM no`;

- `PasswordAuthentication` is `yes`, the default;

- there is an account with no password, with `*` in its password field (for example users created with `adduser` without a password, or the `alpine` user in the cloud images);

- and at least one other local account has a password.

Affected branches: Alpine 3.16 to 3.24 and edge.
Fixed `openssh` package versions (Alpine advisory): 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. Point releases 3.21.10, 3.22.8, 3.23.8 and 3.24.4 already ship them.
Alpine cloud images: per the advisory, the official tiny-cloud images (qcow2, VHD and AMI) from 3.18.11 to 3.24.3 include an `alpine` user with no password that can become root. They are safe on first boot but become exploitable as soon as the machine has any account with a password.
Not affected (per Alpine): Docker containers that don't run sshd, servers with `PasswordAuthentication no`, `openssh-server-pam` with `UsePAM yes`, locked accounts, and machines with no password-bearing accounts. According to The Hacker News, glibc-based Linux such as Debian or Ubuntu is not affected either.
Who found it: Özgün Kültekin of Wakefield, per Alpine and OpenSSH. No CVE number had been assigned at publication.

What changes and what doesn't

It changes things for any Alpine VPS or virtual machine that accepts SSH passwords: until it's updated, an account meant for key-only access can become a way in.
Nothing changes if you log in only with SSH keys and have `PasswordAuthentication no`.
It doesn't affect the website itself (WordPress, Drupal or your app), nor most Alpine-based Docker containers, which don't run an SSH server: the risk is in access to the server.

How to tell if you're affected

If you run a VPS or server on Alpine:

Check the branch: `cat /etc/alpine-release`.
Check the package version, not the OpenSSH version: run `apk info -v openssh-server` (or `openssh-server-pam`) and compare it with the list above. On stable branches the fix is backported into older OpenSSH releases, so `ssh -V` won't tell you whether you're protected.
Update and restart sshd. Alpine gives `apk upgrade -U -a` followed by `rc-service sshd restart`: upgrading the package does not restart the sshd that is already running.
If you can't update today, Alpine suggests turning off password logins (`PasswordAuthentication no`). First make sure your key works, and keep your current session open until you've confirmed it.
Look for intrusions: Alpine advises searching `/var/log/messages` for «Accepted password for» lines from accounts that shouldn't log in with a password, and reviewing new users and `authorized_keys` files.

If you use Alpine cloud images (on AWS, for example): instances launched from images older than 3.21.10, 3.22.8, 3.23.8 or 3.24.4 won't fix themselves; update each one or turn off password logins.

If your site runs in Alpine-based Docker containers (the `-alpine` images of nginx, PHP or Node.js): if the container doesn't run sshd, Alpine says you're not affected. Rebuilding on the updated base image is still a good idea.

If your site is on shared hosting: this isn't on you. To confirm, ask your provider: «Do any of your SSH-accessible servers run Alpine Linux? Have they installed the fixed openssh package from 5 November?».

If your server runs Debian or Ubuntu: according to The Hacker News this flaw doesn't affect you, though those systems did get an important package-manager fix this week.

Sources

Updates: if a CVE is assigned or attacks are confirmed, it will be added here with a link.