OpenSSH releases critical fix for musl password-authentication bypass

OpenSSH released version 10.6p2 on November 5, 2026, to close a critical password-authentication bypass on musl-based Linux systems such as Alpine Linux. OpenSSH rates the flaw critical, according to The Hacker News. Researcher Özgün Kültekin of Wakefield published technical details the same day under the name “*sshole”. Kültekin said AI agents ran roughly 17,600 authentication tests to find the flaw. No CVE identifier had been assigned at disclosure time. No attacks using the flaw have been reported, according to The Hacker News.

On an affected system, an attacker who knows the name of an account with no usable password sends a password between 257 and 1,024 bytes. The musl C library’s crypt() function returns an asterisk when hashing fails for passwords longer than its 256-byte limit. OpenSSH compares that asterisk with the stored asterisk in the target account’s /etc/shadow field and accepts the login. The method does not bypass accounts that have valid password hashes.

Alpine’s advisory states that each attempt with a single connection succeeds and lists four conditions. The server must run openssh-server without PAM or openssh-server-pam with UsePAM no; PasswordAuthentication must be yes, the OpenSSH default; at least one account must have an asterisk as its password field; and a second account must store a $5$ or $6$ password hash. Servers on glibc, such as Debian, Ubuntu, and Fedora, and any system using PAM for password checks are not vulnerable. Non-Linux systems are also unaffected. Instances without a running SSH server, those that set PasswordAuthentication no, and cloud images set up with cloud-init are not affected. Accounts locked with an exclamation mark are not affected.

Alpine’s base image has shipped root with a root:* shadow field since about Alpine 3.16, and official cloud images built with tiny-cloud include an alpine account with passwordless doas. Kültekin warned that Alpine’s official AWS and Azure cloud images contain that account. tiny-cloud images 3.18.11 to 3.24.3 start secure but become vulnerable when any $6$ hash is added, for example by setting a console password. After that, an attacker can authenticate as alpine and run doas to get root. Direct root login is blocked by the default PermitRootLogin prohibit-password setting.

OpenSSH 10.6p2 includes a workaround that refuses a match when the stored password field is shorter than four characters. Alpine released patched packages for every release back to 3.16, including branches 3.16 through 3.21 that are past end of support, and point releases 3.21.10, 3.22.8, 3.23.8, and 3.24.4. Administrators should run apk upgrade -U -a and then rc-service sshd restart, because the package update alone leaves the old sshd process running. Where patching must wait, setting PasswordAuthentication no and restarting sshd stops the attack. OpenSSH’s Damien Miller told users to “set PasswordAuthentication=no or disable SSH for these systems IMMEDIATELY.”

Alpine’s advisory recommends checking /var/log/messages for sshd lines that read “Accepted password for” an account that should have none, such as alpine, root, or a key-only user. Defenders should also look at doas usage and new users, files, and authorized keys. “If you cannot rule out a login, treat the machine as compromised,” the advisory says.