Alpine SSH bypass: a 257-byte password opens key-only accounts

OpenSSH 10.6p2, released on November 5, works around a password bypass in sshd. It hits Linux systems that use the musl C library with PAM disabled. Alpine Linux is the example the OpenSSH team names, and its security advisory says an attacker who can reach the SSH port can log in without knowing any password, in one connection. If you run sshd on Alpine anywhere, update and restart today.

OpenSSH developer Damien Miller posted the release at 09:03 UTC with a blunt instruction: on musl systems without PAM, set PasswordAuthentication to no or disable SSH “IMMEDIATELY.” He says glibc systems, non-Linux systems and systems that use PAM for passwords are not affected.

A long password matches an empty one

The cause sits between two pieces of software. Alpine’s advisory explains that sshd without PAM checks a password by running it through crypt() and comparing the result with the stored password field. For an account whose field is too short to hold a salt, sshd borrows the salt of another account.

musl’s crypt() returns the string * as an error when the password is longer than 256 bytes. But * is also what the stored field holds for every account with no password set, such as key-only users. So the “hash” matches and the login succeeds. OpenSSH calls the root cause “outside sshd” but fixed it there because sshd is where it can be exploited.

Alpine lists three conditions. PasswordAuthentication is left at yes, the OpenSSH default. One account has * as its password field, and at least one other has a $5$ or $6$ hash. The password sent must be 257 to 1,024 bytes.

Who is exposed

Alpine’s default openssh-server package is built without PAM, so it is affected. So is openssh-server-pam with UsePAM set to no. Root ships as root:* since about Alpine 3.16. The default PermitRootLogin setting blocks password logins for root, so the risk there is another account that can become root through doas.

The official tiny-cloud images, from 3.18.11 through 3.24.3, ship an alpine user with a * field. That user also gets passwordless doas. The images are safe on first boot but become exploitable once any $6$ hash exists, for example after an admin sets a console password. Docker users who do not run sshd in the container are not affected, and nor are images set up through cloud-init, which turns password logins off.

Why the fix shipped within a day

Miller says the team learned of the problem the day before release and moved fast because it has seen AI agents rediscover bugs “sometimes within hours.” He calls long embargo periods “a dangerous practice that primarily benefits attackers.” The release notes add that OpenSSH will, for now, ship fixes more often instead of batching them.

The trade-off for admins is more frequent updates on a shorter clock, sometimes before a CVE exists. None had been assigned for this bug when Alpine published.

We checked Alpine’s package index at about 14:40 UTC: the fixed openssh-server builds for edge, 3.24 and 3.21 are dated between 08:59 and 09:05 UTC on November 5. On Docker Hub, the alpine:latest and 3.24 tags were last updated on October 23. So an image that installed openssh-server before today keeps the old package until you rebuild it or upgrade inside it.

What to do now

• Update and restart. Run apk upgrade -U -a, then rc-service sshd restart; the upgrade alone does not replace the running daemon. Fixed versions include 10.6_p2-r0 (edge), 10.3_p1-r2 (3.24), 10.2_p1-r1 (3.23), 10.0_p1-r11 (3.22) and 9.9_p2-r1 (3.21). Alpine 3.21.10, 3.22.8, 3.23.8 and 3.24.4 carry them.
• If you cannot update, turn password logins off. Confirm key login works first, set PasswordAuthentication no, then check with sshd -T | grep -i passwordauthentication.
• Do not skip old releases. 3.21 left support on November 1, but Alpine published fixed packages back to 3.16.
• Rebuild images that bake in openssh-server, including tiny-cloud instances started from older point releases.
• Check the logs. Search /var/log/messages for “Accepted password for” on an account with no password, such as alpine or root. If you cannot rule out a login, Alpine says to treat the machine as compromised.

Sources

• OpenSSH, release notes for OpenSSH 10.6p2, November 5, 2026: https://www.openssh.com/txt/release-10.6p2
• Damien Miller, OpenSSH 10.6p2 announcement, November 5, 2026: https://hachyderm.io/@damienmiller/117563026759098135
• Alpine Linux, “Security advisory: openssh-server password authentication bypass,” November 5, 2026: https://alpinelinux.org/posts/2026-11-05-openssh-password-authentication-bypass/
• Alpine Linux, “Alpine 3.21.10, 3.22.8, 3.23.8 and 3.24.4 released,” November 5, 2026: https://alpinelinux.org/posts/alpine-3.21.10-3.22.8-3.23.8-3.24.4-released/
• Alpine Linux package index, openssh-server, read November 5, 2026: https://pkgs.alpinelinux.org/packages?name=openssh-server&branch=v3.24&arch=x86_64
• Docker Hub, alpine official image tags, read November 5, 2026: https://hub.docker.com/_/alpine