6 NOV 2026 — The OpenSSH project released Portable OpenSSH 10.6p2 on 5 November as an urgent fix for a password authentication bypass on Linux systems that use the musl C library without PAM, the default build of the SSH server on Alpine Linux. On an affected machine, anyone who can reach the SSH port can log in to an account that has no password set, such as a key-only user, by sending a very long password. Alpine shipped fixed packages for every release back to 3.16 the same day. The flaw is tracked as CVE-2026-123158. Özgün Kültekin of Wakefield, who reported it, has named it "*sshole".
Alpine's security advisory explains how the login goes through. Without PAM, sshd verifies a login by running the typed password through the C library's crypt() function and comparing the output with the account's entry in the shadow file. If that entry holds no salt, sshd uses one taken from a different account, behaviour that OX Security's analysis traces to a 2016 OpenSSH change meant to stop attackers learning which usernames exist. musl's crypt() refuses any key over 256 bytes and reports the failure by returning "*". An account with no password stores that same single character, so the two match and sshd lets the attacker in. Alpine says it takes one connection.
"We consider the root cause of this bug to be outside sshd, but it is exploitable via sshd and can be avoided there," the OpenSSH release notes say. The upstream change stops a stored password field shorter than four characters from counting as a match. The pattern recalls a GitLab flaw at Alpine Linux whose fix lived in Ruby.
Who is exposed, and who is not
Alpine lists four conditions, and all must hold. The server has to be running Alpine's default openssh-server package, which is built without PAM support, or the PAM build with UsePAM turned off, and password authentication has to be on, as it is out of the box. The attack then needs an account with "*" in its password field and a second local account with a real $5$ or $6$ hash to supply the salt. One user with a password exposes every account without one.
Accounts with "*" are common on Alpine. The advisory names root in the base image (since roughly 3.16), key-only users added without a password, users supplied by a directory service through musl-nscd, and the default alpine account in the official tiny-cloud images. OpenSSH's default root-login setting keeps root itself out, but that is no protection if any reachable account can escalate, for instance with doas. The tiny-cloud images released between 3.18.11 and 3.24.3 give the alpine account doas without a password. Alpine says they are safe when first booted and vulnerable once any $6$ hash appears, such as when an administrator sets a console password.
Damien Miller's announcement to the OpenSSH developers' list sets the outer limit: "This vulnerability does not exist on non-Linux systems, Linux/glibc systems and Linux systems that use PAM for password authentication." Alpine also rules out containers with no sshd inside, servers with password logins switched off, accounts locked with "!", and images set up by cloud-init, because cloud-init disables password logins. Kültekin's write-up and OX Security name OpenWrt, Buildroot and Yocto as other musl systems where the same conditions apply, and both say Dropbear is safe.
Which Alpine packages carry the fix
The advisory gives a fixed openssh version for ten branches. We checked each against Alpine's own package index for the main repository on x86_64, downloaded at 05:40 UTC on 6 November. In all ten, openssh-server and openssh-server-pam were at the named version.
| Alpine branch | Fixed openssh version | In package index | Package build time, 5 Nov (UTC) |
|---|---|---|---|
| edge | 10.6_p2-r0 | Yes | 09:05 |
| 3.24 | 10.3_p1-r2 | Yes | 09:00 |
| 3.23 | 10.2_p1-r1 | Yes | 09:00 |
| 3.22 | 10.0_p1-r11 | Yes | 09:00 |
| 3.21 | 9.9_p2-r1 | Yes | 09:00 |
| 3.20 | 9.7_p1-r6 | Yes | 06:53 |
| 3.19 | 9.6_p1-r3 | Yes | 06:53 |
| 3.18 | 9.3_p2-r4 | Yes | 06:53 |
| 3.17 | 9.1_p1-r7 | Yes | 06:53 |
| 3.16 | 9.0_p1-r6 | Yes | 06:53 |
Six of those ten branches are out of regular support. Release 3.21 has been out of support since 1 November, and releases 3.16 through 3.20 no longer receive regular updates. Alpine patched them anyway, and it names a point release on each of 3.21 to 3.24 that includes the fix. The upstream commit is dated 08:18 on 5 November at UTC+11, which is 21:18 UTC on 4 November. By our arithmetic, the first Alpine builds arrived 9 hours 35 minutes later, and the edge build arrived 11 hours 47 minutes after the commit.
One record lagged. Alpine's security database, the JSON feed of fixed vulnerabilities per branch, listed neither CVE-2026-123158 nor any of the new versions in any branch when we read it at the same time. The advisory says no CVE number existed when it was written, and the NVD record, published at 16:17 UTC on 5 November, still showed the status "Received", meaning NVD had not analysed it. Anyone judging exposure from that feed alone should check the installed version directly.
Checking and fixing a machine
Alpine's fix is apk upgrade -U -a followed by rc-service sshd restart. "Upgrading the package alone does not replace the running daemon," the advisory warns. If the update must wait, the advisory says to turn off password logins and restart sshd after confirming that key login works, and to keep the current session open. sshd -T | grep -i passwordauthentication should then report no. OX Security says Docker and cloud images built on the old package need rebuilding, and warns against running unverified checker scripts from public repositories.
To spot a break-in, Alpine says to look for "Accepted password for" lines in /var/log/messages naming an account that has no password, and to check doas activity, new users, changed files and authorised keys. "If you cannot rule out a login, treat the machine as compromised." The Register reported no indication of exploitation so far. The CVE record scores the flaw 8.1, High, on CVSS 3.1, and CISA's entry in it records the exploitation status as proof of concept.
Found with agents, fixed in a day
Kültekin writes that he built sshd against glibc and musl, with and without PAM, then threw about 17,600 login attempts at the builds. Only the musl build without PAM accepted logins it should have refused. He credits "agent swarms" for the work. Miller wrote that the project learned of the bug the day before release. He added: "we have recently observed multiple cases of rapid bug rediscovery by AI agents, sometimes within hours, and so now consider long embargo periods to be a dangerous practice that primarily benefits attackers." OpenSSH says it will, for now, ship fixes more often instead of holding them for planned releases.
View author profile → · Editorial policy
