OpenSSH Vulnerability on Alpine Linux: Long Passwords Bypass SSH Login on Accounts With No Password, and the Fixed Versions to Install

A flaw in how OpenSSH checks passwords on Alpine Linux lets someone log into certain accounts that have no password set, just by sending a very long password. If your company runs Alpine servers, virtual machines or cloud images with SSH reachable, install the fixed openssh packages and restart sshd this week, or turn password logins off.

What happened

On Thursday, November 5, 2026, Alpine Linux published a security advisory titled as an OpenSSH password authentication bypass, and the OpenSSH project released Portable OpenSSH 10.6p2. The OpenSSH release notes describe the fix as a change to "avoid password authentication bypass that is exploitable through sshd(8) that affects some Linux systems."

Alpine credits Özgün Kültekin of Wakefield with the report, Damien Miller and Darren Tucker of OpenSSH with the fix, Timo Teräs with analysis and Natanael Copa with building the packages. Alpine's advisory says no CVE number had been assigned at the time of writing.

What is confirmed and what is claimed

Confirmed by Alpine and OpenSSH:

• The bypass is real and fixed in OpenSSH 10.6p2 and in patched Alpine packages for every branch from 3.16 to edge.
• It only works when a specific set of conditions is true (listed below).
• Alpine's official tiny-cloud images from 3.18.11 through 3.24.3 ship an alpine user with no password and passwordless doas, which becomes exploitable once any account on the machine has a $6$ password hash.

Claimed by the researcher in their write-up:

• The password has to be between 257 and 1,024 characters long.
• Other Linux systems built on the musl C library, such as OpenWrt, Buildroot, Yocto builds and many Docker images, can meet the same conditions.
• Systems using glibc (Debian, Ubuntu, Fedora), setups using PAM, Dropbear and OpenBSD are not affected.

Not known:

• Whether anyone has used this against real servers. The researcher writes: "as far as anyone knows, nobody noticed." Neither Alpine nor OpenSSH reports attacks.
• When a CVE number will be assigned.

How the OpenSSH Alpine bypass works

When OpenSSH runs without PAM, it checks a password by hashing what you typed and comparing the result to the stored entry in the shadow file. An account with no password has just * stored there.

Because * contains no salt, sshd borrows the salt from another account on the machine. Alpine uses musl, and musl's password hashing function refuses passwords longer than 256 bytes for $5$ and $6$ hashes. When it refuses, it returns *. That * then matches the stored *, and sshd lets the user in.

In plain terms: an account meant to accept only SSH keys, or no login at all, can be opened by anyone who knows the username and sends one long password. It is not a guessing attack.

OpenSSH 10.6p2 makes sshd refuse a match when the stored entry is too short to be a real hash. Alpine's stable branches carry a patch for the same problem.

Is my Alpine server affected?

Alpine says a machine is exposed only when all four of these are true:

1. It runs the openssh-server package (built without PAM), or openssh-server-pam with UsePAM no.
2. PasswordAuthentication is yes, which is the OpenSSH default.
3. An account has * as its password field.
4. At least one other local account has a $5$ or $6$ password hash.

Accounts Alpine lists as at risk:

• root, which Alpine has shipped as root:* since about 3.16, but only if PermitRootLogin yes is set.
• Users set up for SSH keys only, created without a password.
• Users that come from a directory service and have no local shadow entry.
• The alpine user in tiny-cloud images.

Alpine says you are not affected if sshd is not running (for example most containers), PasswordAuthentication is no, you use openssh-server-pam with UsePAM yes, the account is locked with !, or no account on the system has a $-style hash. Cloud images configured with cloud-init are not affected because cloud-init turns password logins off.

OpenSSH Alpine fix: versions to install

These are the fixed openssh package versions from Alpine's advisory:

The point releases 3.21.10, 3.22.8, 3.23.8 and 3.24.4 include the fix. If you build OpenSSH from source on any musl-based system, use 10.6p2.

What to do this week

• List your Alpine machines. Include cloud VMs, bastion or jump hosts, appliances and any container that runs its own sshd.
• Check the installed version: apk info -v | grep openssh, then compare against the table above.
• Update: apk upgrade -U -a
• Restart SSH: rc-service sshd restart. Alpine's advisory includes this step; the running sshd keeps the old code until it restarts.
• If you cannot update yet, turn off password logins. First confirm key login works and keep your current session open. Set PasswordAuthentication no using a drop-in file in /etc/ssh/sshd_config.d, as the advisory describes, and check for other PasswordAuthentication lines, including inside Match blocks. Test with sshd -t, restart sshd, then run sshd -T | grep -i passwordauthentication. Alpine says it should print passwordauthentication no.
• Look for signs of a break-in. Search /var/log/messages for Accepted password for on accounts that have no password. Review doas use, recently created users, new files and authorized_keys entries. Alpine's advice: if you cannot rule out a login, treat the machine as compromised.
• Ask your vendors. If you run routers, firewalls or appliances built on OpenWrt, Buildroot or Yocto with OpenSSH enabled, ask the vendor whether their build is affected.

Why it matters for a business

Alpine is popular because it is light. That is why it ends up in places nobody logs into every day: a cloud jump box, a build server, a monitoring VM, the operating system inside a vendor appliance. Those are exactly the machines that tend to keep default settings for years.

The risky combination here is made of defaults: password logins on by default, key-only accounts stored as *, and one other account with a normal password. On tiny-cloud images, the alpine user also has passwordless doas, so a login there can become full control of the machine. For a company network, one forgotten Alpine host with SSH open can be the first step into everything it can reach.

Key-only SSH, with password logins switched off everywhere, removes this whole class of problem. If you rely on a provider or contractor for your servers, ask them to confirm in writing which Alpine hosts they updated and restarted.

OpenSSH Alpine vulnerability questions people are asking

Is there a CVE for the OpenSSH Alpine flaw?

Not yet. Alpine's advisory says no CVE number had been assigned at the time of writing. Track it by the fixed package versions instead.

Are Ubuntu, Debian and other Linux servers affected?

The researcher says glibc systems such as Debian, Ubuntu and Fedora are not affected, and neither are setups using PAM. The OpenSSH release notes say the flaw affects "some Linux systems."

Are Alpine Docker containers affected?

Only if the container runs sshd and meets the other conditions. Alpine says containers that do not run sshd are not affected.

Does updating Alpine restart SSH automatically?

Restart it yourself with rc-service sshd restart after apk upgrade, as Alpine's advisory instructs.

What if I cannot update right away?

Set PasswordAuthentication no, test with sshd -t, restart sshd and confirm with sshd -T. Make sure key login works first.

How do I know if someone got in?

Search /var/log/messages for Accepted password for on accounts with no password, and review doas use, new users and SSH keys. If you cannot rule it out, rebuild the machine.

The bigger lesson

This bug needed four ordinary settings to line up, and each one looked harmless alone. Servers stay safe when someone owns the boring work: turning off password logins, knowing which machines exist, and confirming that an update was actually installed and restarted.

Want your servers hardened and kept patched? See security hardening or request a quote.

Get security alerts like this by email, with our free checklist, at /security-alerts.

Sources: Alpine Linux security advisory; OpenSSH release notes; Özgün Kültekin's write-up.