Alpine Linux and the OpenSSH project have shipped fixes for a password authentication bypass that can let an attacker log into certain accounts that were never meant to accept a password.
Researchers call the flaw *sshole. It shows up when OpenSSH runs on musl-based Linux without PAM—Alpine’s usual setup, and one that also appears on OpenWrt, Buildroot and Yocto. Alpine published its advisory on 5 November 2026. Portable OpenSSH 10.6p2 arrived the same day with what the project labels a critical security workaround.
Özgün Kültekin of Wakefield reported the bug. On X, he urged operators of Alpine, OpenWrt and other musl systems that still allow password authentication to update immediately.
What goes wrong
Linux accounts that should reject passwords often store a lone asterisk (*) in /etc/shadow instead of a real password hash. On musl, the C library function that hashes passwords can also return * when hashing fails, including when a submitted password is longer than musl’s 256-byte limit.
When OpenSSH is built without PAM, it compares the hashed attempt with the stored field. If both sides are *, the comparison succeeds. Alpine says an attacker who can reach the SSH port, knows a suitable account name, and meets a few other local conditions can log in without knowing any password. The advisory says it takes one connection and does not need retries.
Alpine lists the conditions as: the default openssh-server package without PAM (or openssh-server-pam with UsePAM no); PasswordAuthentication still set to yes; at least one account whose password field is *; and at least one local account with a modern $5$ or $6$ password hash. OpenSSH’s release notes say the root cause sits outside sshd, but the bug is exploitable through sshd and can be avoided there.
Who is at risk
Affected Alpine releases include current branches Alpine checked from 3.21 through 3.24 and edge, plus older unsupported releases from 3.16 to 3.20. Alpine has published fixed packages back to 3.16.
Not every Alpine or musl box is exposed. Alpine says you are not affected if you do not run sshd, if PasswordAuthentication is already no, if you use openssh-server-pam with UsePAM yes, if accounts are locked with ! rather than *, or if no account has a $-style password hash. Cloud images that already set PasswordAuthentication no through cloud-init are also outside the advisory’s “affected” path.
Alpine’s tiny-cloud images are a sharper case. Official images from 3.18.11 through 3.24.3 ship an alpine user with a * password field and passwordless doas. They are safe on first boot, the advisory says, but become exploitable once any $6$ hash appears on the machine—for example after an admin sets a console password. An attacker who reaches alpine can then use doas to become root. Images built from 3.21.10, 3.22.8, 3.23.8, 3.24.4 and later include the fixed package.
glibc distributions such as Debian, Ubuntu and Fedora, and systems that use PAM for OpenSSH authentication, are outside this musl-without-PAM failure mode, according to the disclosure write-up and Alpine’s advisory.
What to do
Alpine’s first instruction is blunt: update openssh and restart sshd. Upgrading the package alone does not replace a running daemon. Fixed package versions are listed per branch in the advisory, including edge 10.6_p2-r0 and branch packages such as 3.24’s 10.3_p1-r2.
If you cannot update yet, Alpine says to disable password logins by setting PasswordAuthentication no and restarting sshd. Keep an existing session open until you have tested a new key-based login. Alpine also says either the update or that configuration change closes the hole.
How to check for abuse
Alpine recommends looking in /var/log/messages for sshd lines that read “Accepted password” for accounts that have no password—such as alpine, root or any key-only user—and reviewing doas use plus recently created users, files and authorised keys. If you cannot rule out a login, treat the machine as compromised.
CVE status
Alpine said no CVE identifier had been assigned at the time of writing. Later secondary trackers, including Akamai Linode’s status advisory, refer to CVE-2026-123158. Treat that identifier as the label those trackers are using, and rely on Alpine’s package versions and OpenSSH 10.6p2 for the fix.
Reaction
On Hacker News, Kültekin’s *sshole write-up drew thousands of points within hours of publication. On X, higher-reach security accounts such as Cyber Security News and sysxplore pushed the same message: update now if password authentication is still enabled on musl systems.
Sources
- Alpine Linux security advisory (5 Nov 2026)
- OpenSSH 10.6p2 release notes
- *sshole disclosure site
- Özgün Kültekin on X
- BleepingComputer report
- Akamai Linode customer security advisory
Discover more from Sulat — AI & Tech News
Subscribe to get the latest posts sent to your email.
