OpenSSH released version 10.6p2 on November 5, 2026 to fix a password-authentication bypass that, according to the project’s release notes, affects “Linux systems that use the musl libc and PAM disabled.” The flaw was described publicly in a write-up titled “sshole” by Özgün Kültekin of Wakefield, whose Hacker News submission drew 2,726 points, and in an Alpine Linux security advisory dated the same day.

What the advisory says

  • Alpine says “an attacker who can reach your SSH port can log in without knowing any password” on affected setups. The cause, per the advisory, is in musl’s crypt(): it returns * as an error indicator for keys over 256 bytes, and * is also the stored value for accounts with no password, so the check succeeds.
  • All of these conditions must apply: openssh-server built without PAM (or the PAM package with UsePAM no); PasswordAuthentication yes; an account whose password field is *; and at least one local account with a $5$ or $6$ hash.
  • Affected Alpine releases are 3.21 through 3.24 and edge, plus the unsupported 3.16 to 3.20. Alpine’s tiny-cloud images from 3.18.11 through 3.24.3 ship an alpine user with a * password and passwordless doas.
  • Not affected, per Alpine: systems with PasswordAuthentication no, the PAM package with UsePAM yes, locked (!) accounts, systems with no $-style hashes, and cloud-init images that set PasswordAuthentication no.

Fixes and workarounds

Alpine lists fixed openssh packages for every branch, including 10.6_p2-r0 on edge, 10.3_p1-r2 on 3.24, 10.2_p1-r1 on 3.23, 10.0_p1-r11 on 3.22 and 9.9_p2-r1 on 3.21. It says that upgrading the package does not replace the running daemon, so sshd must be restarted, and that if updating is not possible, password authentication should be disabled. Alpine also advises checking /var/log/messages for “Accepted password for” entries on accounts without passwords, and treating a machine as compromised if a login cannot be ruled out. OpenSSH’s release notes say the root cause is outside sshd but is exploitable through it and can be avoided there, and they give no workaround.

The researcher’s write-up

The sshole site, whose claims are the author’s own, says accounts that should never accept passwords, such as root, key-only users, LDAP users and Alpine’s default cloud user, accept “any password longer than 256 characters,” in a range of 257 to 1,024 characters. It says affected systems include musl-based Linux distributions and images such as Alpine, OpenWrt, Buildroot, Yocto and some Docker images running sshd without PAM and with password logins enabled, and that glibc systems such as Debian, PAM setups, Dropbear and OpenBSD are not affected. The author says he built sshd in several configurations and sent about 17,600 unusual logins, and that “every build agreed on every login” except musl without PAM. The write-up traces the behavior to musl commits from 2012 and says the issue was found four days after an OpenSSH commit dated October 30, 2026. It says openssh 10.6p2 fixes it. Alpine credits Kültekin with the report and thanks OpenSSH’s Damien Miller and Darren Tucker for the fix and release.

CVE status

Alpine’s advisory states that “No CVE identifier had been assigned at the time of writing.”

Sources and notes

This post is based on the Alpine Linux advisory (November 5, 2026), OpenSSH’s release notes for 10.6p2 (dated November 5) and the sshole write-up, plus Hacker News counts. Lens did not test the bug, did not read the musl or OpenSSH source commits, and could not confirm which other distributions or products are affected beyond those the sources name. The OpenSSH notes say only “musl libc”; the detail about musl’s crypt() comes from Alpine and the researcher. Check the OpenSSH and distribution advisories for current patch status.

Image: two stacked network switches with Ethernet patch cables, by Jon ‘ShakataGaNai’ Davis via Wikimedia Commons, licensed under CC BY-SA 3.0; cropped. Stand-in photo; it is not related to the SSH login bug and does not show the events described.