OpenSSH 10.6p2 fixes Alpine Linux password bypass

Alpine Linux and the OpenSSH project shipped fixes on November 5, 2026, for a bug that lets an attacker log in to some Alpine servers over SSH without any password. Anyone running Alpine's default SSH server with password logins switched on should update and restart it today.

The flaw "takes one connection, works every time, and needs no retries," the Alpine security advisory says. Özgün Kültekin of Wakefield reported it. No CVE number had been assigned when Alpine published, and neither project reports any attacks.

How the password bypass works

The bug sits where OpenSSH meets musl, the small C library Alpine uses instead of glibc. It only appears when sshd, the SSH server, runs without PAM, the shared login system most Linux distributions use.

Without PAM, sshd hashes the password attempt with crypt() and compares the result with the account's entry in /etc/shadow. Alpine explains that musl's crypt() returns * as an error for keys over 256 bytes. An account with no password stores that same *, so a password of 257 to 1,024 bytes "matches." An account with no usable salt, the random text that makes each hash unique, borrows another account's salt. That is why one local account needs a real $5$ or $6$ hash.

The OpenSSH 10.6p2 release notes call the update "a critical security workaround" and place the root cause "outside sshd." It follows OpenSSH 10.6, which shipped in October with post-quantum signatures.

Kültekin's write-up names the bug "sshhole" and traces it to two musl commits from August 2012. Of about 17,600 test logins, only musl without PAM behaved differently. It also names OpenWrt, Buildroot and Yocto, which Alpine and OpenSSH do not mention.

Who is affected, per Alpine's advisory

A machine is exposed only when all four conditions hold:

• sshd comes from openssh-server, built without PAM, or from openssh-server-pam with UsePAM no.
• PasswordAuthentication is yes, the default.
• An account has * as its password field, such as root, a key-only user or a directory user from sssd.
• At least one local account has a $5$ or $6$ hash.

Containers that do not run sshd are safe, and so are locked accounts marked !. The default PermitRootLogin prohibit-password blocks password logins for root. It does not protect an account that can become root through doas. Alpine's tiny-cloud images from 3.18.11 through 3.24.3 ship such an alpine user, with * and passwordless doas.

Tested: five Alpine images and their defaults

In a Tech AI Wire test on November 5, on macOS 26.6.2 with Docker 28.4.0, the official alpine images installed openssh-server from Alpine's live mirrors.

Branch	Image release (built)	Package installed	Alpine's fixed version	sshd -V
3.21	3.21.9 (Oct 21)	9.9_p2-r1	9.9_p2-r1	OpenSSH_9.9p2
3.22	3.22.7 (Oct 21)	10.0_p1-r11	10.0_p1-r11	OpenSSH_10.0p2
3.23	3.23.7 (Oct 21)	10.2_p1-r1	10.2_p1-r1	OpenSSH_10.2p1
3.24	3.24.3 (Oct 21)	10.3_p1-r2	10.3_p1-r2	OpenSSH_10.3p1
edge	3.25.0_alpha20260805 (Aug 6)	10.6_p2-r0	10.6_p2-r0	OpenSSH_10.6p2

Four results matter:

• New installs get the fix, but the images predate it. Each reports a release below the fixed 3.21.10, 3.22.8, 3.23.8 and 3.24.4. Stable branches carry the fix inside older OpenSSH versions, so check the package revision, not sshd -V.
• The defaults meet three conditions. All five run PasswordAuthentication yes with root:*. On 3.24, the default sshd rejected UsePAM yes as an "Unsupported option." The openssh-server-pam package's separate sshd.pam program still reported usepam no on 3.21 and 3.24.
• A fresh image misses the fourth. No account has a $5$ or $6$ hash until someone sets a password. One chpasswd call wrote a $6$ hash.
• Making a key-only user work creates a * account. On 3.24, adduser -D appuser wrote !, and sshd refused its key: "User appuser not allowed because account is locked." BusyBox passwd -u left the ! in place. After usermod -p '*', the key login worked.

How to check and fix an Alpine server

Three commands show where a server stands. On 3.24, the test printed:

$ apk list -I "openssh-server*"
openssh-server-10.3_p1-r2 aarch64 {openssh} (SSH-OpenSSH) [installed]
openssh-server-common-10.3_p1-r2 aarch64 {openssh} (SSH-OpenSSH) [installed]
$ sshd -T | grep -i passwordauthentication
passwordauthentication yes
$ awk -F: '$2=="*" {print $1}' /etc/shadow
root

A package older than the table's fixed version needs the update, and Alpine also fixed the unsupported branches 3.16 to 3.20. Run apk upgrade -U -a, then rc-service sshd restart. "Upgrading the package alone does not replace the running daemon," the advisory warns.

If updating must wait, Alpine's workaround is a file, /etc/ssh/sshd_config.d/00-no-passwords.conf, containing PasswordAuthentication no. Confirm key login works first and keep the current session open. In the test, that file turned sshd -T from yes to no on 3.21 and 3.24. Then search /var/log/messages for "Accepted password for" a passwordless account.

What this means for developers

Search Dockerfiles for openssh-server. Images that run sshd for CI runners or remote development are the ones in scope. Rebuild them with docker build --pull --no-cache, so a layer cached before November 5 cannot bring back the old package.

Make PasswordAuthentication no the default for any Alpine machine that only needs keys. Alpine says updating or turning password logins off "closes the hole." The test shows why it matters: the usual way to give a key-only user a working login creates the * account this bug needs.

Watch for a CVE number and for word from OpenWrt, Buildroot and Yocto on which of their builds are exposed. The OpenSSH team also says it will ship releases more often for now.