Coding is Love
News 4 min read

OpenSSH password bypass on Alpine Linux: update to 10.6p2 now

Alpine Linux has published a security advisory for a password authentication bypass in its openssh-server package. An attacker who can reach your SSH port can log in to any account that has no password set, using one connection and no retries, as long as password logins are on and at least one other account has a password hash. OpenSSH fixed the problem in portable release 10.6p2 on 2026-11-05, and Alpine has fixed packages for every release back to 3.16. Alpine’s advice is to update openssh and restart sshd now.

What’s new

  • How the bypass works. When sshd is built without PAM, it checks a password by hashing the attempt with crypt() and comparing it to the stored password field. musl’s crypt() returns * as an error indicator when the key is over 256 bytes. An account with no password has exactly * in its password field, so the comparison matches. Alpine says the attacker sends a password of 257 to 1024 bytes.
  • What the attacker needs. The name of an account whose password field is *, and at least one other account on the machine with a $5$ or $6$ password hash. Alpine notes that one user with a password is enough to make every passwordless account reachable.
  • No CVE yet. Alpine says no CVE identifier had been assigned at the time of writing.
  • Reported by Özgün Kültekin of Wakefield. The OpenSSH release notes call it a “critical security workaround” and say the root cause is outside sshd, although it is exploitable through sshd.

Who is affected

According to Alpine, you are affected if all of these are true:

  • You run the Alpine openssh-server package (built without PAM), or openssh-server-pam with UsePAM no.
  • PasswordAuthentication is yes, which is the OpenSSH default.
  • The machine has an account whose password field is *. That includes root on images since about Alpine 3.16, key-only users created with adduser without a password, users from directory services through musl-nscd, and the alpine user in the official tiny-cloud images.
  • At least one local account has a $5$ or $6$ password hash.

Root is protected by the default PermitRootLogin prohibit-password, but that does not help if another account that can log in can become root, for example through doas. Not affected: containers that do not run sshd, systems with PasswordAuthentication no, openssh-server-pam with UsePAM yes, locked accounts (! in /etc/shadow), and cloud images configured through cloud-init, which writes PasswordAuthentication no.

What it means for developers

Update and restart. Alpine’s fix:

apk upgrade -U -a
rc-service sshd restart

Upgrading the package does not restart a running sshd, so the restart is required. Fixed packages per Alpine: 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, with fixes also published for 3.20 down to 3.16. Alpine 3.21 reached end of support on 2026-11-01 but still got a fixed package.

If you cannot update, disable password logins. Before you do, confirm your key login works and keep your current session open. Alpine’s advisory has a full script; the core of it is setting PasswordAuthentication no and restarting sshd, then checking the result with sshd -T | grep -i passwordauthentication, which should print passwordauthentication no.

Cloud images. Alpine says the official tiny-cloud images from 3.18.11 through 3.24.3 ship an alpine user with a * password and passwordless doas. They are safe on first boot, but become exploitable once any $6$ hash exists, for example when an admin sets a console password or user-data adds a user with a hashed password. Images from earlier point releases do not include the fix, so update running instances or disable password authentication.

Check for signs of attack. Look in /var/log/messages for sshd lines reading Accepted password for an account that has no password (alpine, root, or any key-only user). Review doas use and recently created users, files and authorized keys. Alpine says to treat the machine as compromised if you cannot rule out a login.

How it compares

The flaw sits in how a PAM-less sshd and musl’s crypt() interact, so Alpine’s advisory is about Alpine’s builds. The OpenSSH release notes describe it as affecting “some Linux systems” built and run with PAM support disabled, specifically those using musl libc. If you run another musl-based distribution or build OpenSSH yourself without PAM, check your own setup and take OpenSSH 10.6p2 or your vendor’s patch.

The OpenSSH team also said it has received a large number of security reports, many found with AI models, and will make more frequent releases for now rather than batching fixes. Expect to patch OpenSSH more often.

Keep your deploy tooling in order too: see our guide to 10 Git commands you need.

Sources