OpenSSH 10.6p2 fixes flaw letting oversized passwords log in to password-disabled accounts on Alpine and other musl Linux

TLDR

• OpenSSH 10.6p2 fixes a critical sshd bypass: on musl Linux without PAM, a very long password logs into no-password accounts.³⁴
• Alpine says the attack needs one connection and works every time; fixed packages exist for every branch back to 3.16.⁴
• The Hacker News says no attacks have been reported; the flaw is tracked as CVE-2026-123158, rated 8.1.¹⁶

OpenSSH released Portable OpenSSH 10.6p2 on 5 November 2026 with a fix for a password authentication bypass in sshd that affects some Linux systems built and run with PAM, the Pluggable Authentication Module interface, disabled.³ The release notes call it a critical security workaround for Linux systems that use the musl C library with PAM disabled, and say OpenSSH considers the root cause to be outside sshd.³ The bug was reported by Özgün Kültekin of Wakefield.³ BleepingComputer reports that the flaw, dubbed "*sshole", lets an attacker log in to Alpine Linux and other musl-based accounts that are set up to refuse password logins, simply by entering an oversized password.²

Alpine's advisory sets out the conditions. The attacker must be able to reach the SSH port, know the name of an account whose password field is * (no password set, normal for key-only accounts), and the machine must have at least one other account with a $5$ or $6$ password hash; the attacker then sends a password of 257 to 1,024 bytes.⁴ One account with a password is enough to make every account without one reachable.⁴ A system is affected if it runs Alpine's openssh-server package, which is built without PAM, or openssh-server-pam with UsePAM no, and PasswordAuthentication is yes, the OpenSSH default.⁴ Root has shipped as root:* since about Alpine 3.16 and is protected by the default PermitRootLogin prohibit-password, but that does not help if another account that can log in is able to become root, for example through doas.⁴ The official tiny-cloud images from 3.18.11 through 3.24.3 ship an alpine user with passwordless doas, which Alpine says is safe on first boot but exploitable once any $6$ hash exists on the machine.⁴ Alpine lists containers that do not run sshd, systems with PasswordAuthentication no, openssh-server-pam with UsePAM yes, accounts locked with !, and cloud-init images as not affected.⁴

On the cause, Alpine says musl's crypt() returns * as an error indicator for keys over 256 bytes, which is exactly what the stored field holds for an account with no password, so the "hash" matches.⁴ Kültekin traces the problem to a 2016 OpenSSH change for CVE-2016-6210, which makes sshd hash the attempt with another account's salt when an account has no real hash.²⁵ BleepingComputer says he found it using AI agents that ran about 17,600 authentication tests, and iTnews says the agents built sshd in every combination of glibc, musl, PAM and no PAM.²⁷ The Hacker News quotes OpenSSH's Damien Miller telling affected users to set PasswordAuthentication=no or disable SSH "IMMEDIATELY", and says he described long embargoes as dangerous because AI agents have rediscovered bugs, sometimes within hours.¹

The fix is OpenSSH 10.6p2, and administrators must restart sshd after upgrading because the package update alone does not replace the running daemon.⁴ Alpine published fixed openssh packages for edge (10.6_p2-r0) and for every release from 3.16 to 3.24, including releases past end of support, and says 3.21.10, 3.22.8, 3.23.8 and 3.24.4 already contain the fix.⁴ Setting PasswordAuthentication no and restarting sshd also closes the hole, and Alpine suggests searching /var/log/messages for Accepted password for an account that has no password, adding that a machine where a login cannot be ruled out should be treated as compromised.⁴ The Hacker News reports that no attacks using the flaw have been reported.¹ Cycode, in its own research post, says a small number of public Docker Hub images running an SSH server were exposed under their documented setup, and that images on Alpine releases before 3.16 were exploitable in its lab and get no fixed package.⁸

The sources differ on a few points. Alpine's advisory and The Hacker News said no CVE identifier had been assigned when they were written; the GitHub Advisory Database, iTnews and Cycode list CVE-2026-123158 with a CVSS 3.1 score of 8.1.¹⁴⁶⁷⁸ Alpine, The Hacker News and iTnews give the password length as 257 to 1,024 bytes, while the GitHub advisory says between 256 and 1024 characters.¹⁴⁶⁷ On scope, BleepingComputer lists Alpine, OpenWrt, Buildroot and Yocto as affected musl-based systems, while The Hacker News and iTnews say OpenWrt uses Dropbear by default, which Kültekin says is not affected, so OpenWrt matters only where OpenSSH has been installed.¹²⁷ BleepingComputer and Kültekin's write-up say systems on glibc, including Debian, Ubuntu and Fedora, and systems that check passwords through PAM are not affected.²⁵

Why it matters: Alpine says accounts with no password are normal for key-only users, yet on an affected setup one account with a password makes them all reachable, and the fix takes effect only after sshd restarts.⁴