OpenSSH Authentication Bypass on Alpine Linux Lets Attackers Log In Without a Password
Do Son 
TL;DR
Alpine Linux issued an urgent advisory on November 5, 2026. It warns that an OpenSSH authentication bypass lets attackers log in to sshd without knowing any password. According to Alpine, it “takes one connection, works every time, and needs no retries.” OpenSSH has released version 10.6p2 to block the bug.
sshd builds without PAM can accept a very long password for accounts that have no password set. Every Alpine release from 3.16 to edge is affected. Update openssh and restart sshd, or disable password logins.
Why It Matters
Many Alpine systems run sshd with key-only accounts, which store * in the password field. Those accounts are now reachable. As Alpine puts it, “One user with a password is enough: it makes every account without one reachable.”
Cloud images face extra risk. The official tiny-cloud images ship an alpine user with passwordless doas. Once any password hash exists, an attacker “gets a shell as alpine and can use doas to become root.”
No CVE had been assigned at the time of writing. Neither Alpine, OpenSSH nor the researcher reports exploitation in the wild, and no public exploit code has been released.
Beyond Alpine
The researcher at Wakefield who found the flaw has published a write-up. The site is named after the bug, “*sshole.” It names other musl-based platforms at risk, including OpenWrt, Buildroot and Yocto builds. It also flags “a lot of the docker images” based on Alpine. Still, Alpine says containers that do not run sshd are safe. Meanwhile, glibc systems, PAM setups, Dropbear and OpenBSD are not affected.
How the Attack Works
Without PAM, sshd hashes a password attempt with crypt() and compares the result to the stored field. For accounts with no usable salt, sshd borrows the salt of another account. However, musl’s crypt() returns “*” as an error when the key is over 256 bytes long. Because “*” is exactly what passwordless accounts store, “the ‘hash’ matches and the login succeeds.”
A bug hiding since 2012
The write-up traces the root cause back to August 2012. That year, musl changed crypt() to return “*” on failure and added a 256-byte key limit for SHA-512 hashes. In 2022, Alpine 3.16 changed root’s password field from “!” to “*.” As a result, root now matched the failure string. Yet, as the researcher writes, “as far as anyone knows, nobody noticed.”
To confirm the behavior, the researcher tested roughly 17,600 logins across glibc, musl, PAM and non-PAM builds. Every combination behaved the same, “except musl without pam.” That narrow combination is what turns a libc quirk into an OpenSSH authentication bypass.
The flaw is not limited to Alpine. OpenSSH says it affects “Linux systems that use the musl libc and PAM disabled.” The OpenSSH team notes in its OpenSSH 10.6p2 release notes that it considers “the root cause of this bug to be outside sshd, but it is exploitable via sshd and can be avoided there.”
Affected Versions
- Alpine 3.16 through 3.24 and edge
- The openssh-server package, or openssh-server-pam with UsePAM no
- Systems with PasswordAuthentication yes, the OpenSSH default
- Machines with a passwordless account and at least one $5$ or $6$ password hash
Systems using openssh-server-pam with UsePAM yes are not affected. Neither are cloud-init images, which disable password logins.
Patch and Mitigation
- Run apk upgrade, then restart sshd. “Upgrading the package alone does not replace the running daemon.”
- Fixed builds include openssh 10.6_p2-r0 on edge and 10.3_p1-r2 on 3.24. Alpine also published fixes back to 3.16.
- If you cannot update, set PasswordAuthentication no and restart sshd.
- Check /var/log/messages for “Accepted password” lines on passwordless accounts. The write-up also advises reviewing logins to key-only, LDAP and root accounts.
The researcher’s *sshole write-up includes a browser demo of the crypt() behavior, but no exploit code. Full instructions are in Alpine’s OpenSSH password authentication bypass advisory. Patch this OpenSSH authentication bypass on every exposed Alpine host.
Support Our Threat Intelligence
Find our vulnerability reports and weekly recaps helpful? Support our work today and unlock a 100% ad-free reading experience!
Buy Me a Coffee
