OpenSSH fixes Alpine password bypass a day after report, warning long embargoes aid attackers

OpenSSH has fixed an authentication bypass that allowed password logins to accounts that had no usable password, on Linux systems built with musl libc and without PAM — a combination most closely associated with Alpine Linux. The fix shipped in OpenSSH 10.6p2, released roughly a day after the team was first told about the flaw by Özgün Kültekin of Wakefield, according to a dev.to write-up. No CVE had been assigned at the time of writing, and neither Alpine, OpenSSH nor the researcher reported exploitation in the wild.

When a system is exposed

Per dev.to, drawing on PrivacyAffairs and SecurityOnline, a host is vulnerable only when several conditions line up:

• sshd runs on musl. Alpine is the main case, though Buildroot, Yocto and OpenWrt builds that include OpenSSH can qualify as well.
• sshd checks passwords itself. Alpine's standard openssh-server package is built without PAM, and a PAM build running with UsePAM no is also in scope.
• Password login is on. PasswordAuthentication yes is the OpenSSH default, so silence in sshd_config still counts.
• At least one account has only * in /etc/shadow, the conventional marker for key-only users, LDAP accounts and, since Alpine 3.16, root.
• At least one other account on the machine has a real SHA-256 or SHA-512 password hash.

Not affected: glibc distributions such as Debian, Ubuntu and Fedora, systems that delegate passwords to PAM, OpenBSD, Dropbear, and Alpine containers that never run sshd.

The write-up flags Alpine's official cloud images as the worst case. Tiny Cloud provisions a default alpine user whose shadow password field is * and grants passwordless doas, so once any account on the box has a real password, an attacker who logs in as alpine can escalate to root.

How the bypass works

No single change caused it. Dev.to traces the bug to three decisions made years apart, each defensible in isolation.

In 2012, musl changed crypt() to return * on failure rather than NULL, because many programs never checked for NULL and crashed. Around the same time, musl capped SHA-512 hashing at 256 bytes of input to stop very long passwords from burning CPU; past that limit, hashing fails and returns *.

In 2016, OpenSSH made sshd hash a submitted password even when the target account had no usable hash, borrowing another account's salt, to close a timing leak that revealed which usernames existed (CVE-2016-6210).

In 2022, Alpine 3.16 switched root's shadow password field from ! to *.

Chain them together and a login attempt with a password longer than 256 bytes gets hashed against a borrowed SHA-512 salt; musl abandons the hash and hands back *; sshd compares that to the stored * and they match. The login succeeds. OpenSSH places the root cause outside sshd, while musl's maintainer maintains it is not a musl vulnerability — every component behaved as designed, and the failure only surfaced in a build combination nobody was testing. Kültekin reportedly found it by building sshd across every glibc/musl and PAM/no-PAM permutation and firing about 17,600 unusual login attempts at each, using what he calls "agent swarms."

The 10.6p2 fix is a workaround: sshd now rejects any match where the stored value is shorter than four characters.

A day from report to release

The timeline may matter more than the bug. Coordinated disclosure normally gives distributions private access to patches, with the distros list allowing up to 14 days before publication. Here, according to dev.to, OpenSSH learned of the flaw about a day before release. Alpine's patched packages landed between 06:53 and 09:05 UTC, and Damien Miller announced the release at 09:03 UTC, telling affected admins to switch off password authentication or SSH immediately.

The release notes give the reasoning, as dev.to relays it: the project is receiving a large volume of security reports, many generated by AI models; it has watched bugs found by AI tools be independently rediscovered by other researchers, sometimes within hours; and it concludes that attackers who never file reports can probably find them too. OpenSSH now describes long embargoes as "a dangerous practice that primarily benefits attackers" and plans to ship fixes in more frequent releases. This particular bug was itself found with agents.

Patching guidance

On Alpine, run apk update && apk upgrade and then restart the daemon with rc-service sshd restart, since upgrading the package does not replace a running sshd. Per dev.to, fixed builds reach back to Alpine 3.16, for example 10.6_p2-r0 on edge and 10.3_p1-r2 on 3.24. Container images built on affected versions should be rebuilt, and where patching cannot happen at once, disabling password authentication closes the bypass.

Why it matters

Two stories are stacked here. The first is operational: a real authentication bypass affecting a build pattern — Alpine plus non-PAM sshd plus default password auth — that is common in small containers and embedded images, with no CVE for scanners to key on during the first critical hours. The second is structural: if AI agents can find and refind a bug like this within hours, the weeks-long embargo defenders implicitly relied on is gone. What remains in a defender's control, as the dev.to piece puts it, is how quickly a fix gets noticed and how much of the fleet was ever exposed — which makes daily monitoring of vendor release notes and distribution advisories, rather than CVE feeds alone, part of the patching process.