A decade-old authentication bypass in OpenSSH on musl-based Linux lets attackers log into accounts that should never accept a password. The flaw, dubbed *sshole, is tracked as CVE-2026-123158.
Any password between 257 and 1,024 characters works. It affects Alpine Linux, OpenWrt, Buildroot, and Yocto, and the OpenSSH team shipped version 10.6p2 on November 5, 2026, to block it.
OpenSSH sshole Flaw
Security researcher Özgün Kültekin of Wakefield discovered the issue. Accounts with no password, such as root, key-only deploy users, and LDAP users, store an asterisk (*) in their password field. No hash can ever match that character, so these accounts normally stay closed to password logins.
The trouble starts with the musl C library. Since 2012, musl’s crypt() function has returned an asterisk on failure instead of a NULL pointer, as the Single UNIX Specification describes. Weeks later, musl capped SHA-512 password input at 256 bytes to prevent CPU-exhaustion attacks. Any longer password makes crypt() fail and return “*”.
OpenSSH added the final piece in 2016. To stop username enumeration through timing differences, sshd borrows another account’s salt when an account has no usable one, and hashes the attempt anyway. With a 257-byte or longer password, the hash fails and returns ““.
sshd then compares that “” with the account’s stored “*”, sees a match, and grants access. The researcher’s public repository shows that two prompts are enough: any wrong password first, then about 300 “A” characters.
Exploitation needs several conditions at once, according to Check Point and the researcher’s checks:
- sshd runs on musl without PAM, which is Alpine’s default openssh-server build.
- PasswordAuthentication is enabled, which is the OpenSSH default.
- An account has exactly “*” as its password field.
- Another active local account has a real $5$ or $6$ hash, because sshd borrows that salt.
Alpine’s official cloud images for AWS and Azure raise significant concerns. The default user, “alpine,” has passwordless access to doas, which can give attackers root privileges. However, systems that use glibc (such as Debian, Ubuntu, and Fedora), PAM-based authentication, Dropbear, or OpenBSD are not affected. So far, no exploitation has been reported in the wild.
The bug survived for ten years because OpenSSH is tested mainly on OpenBSD and glibc, and musl does not test sshd. Most distributions also route logins through PAM, which never calls crypt() for an asterisk. Kültekin found the flaw with AI agents that ran roughly 17,600 unusual logins against sshd builds across glibc, musl, PAM and shadow combinations.
Every build agreed except musl without PAM. The OpenSSH release notes say they consider the root cause to be outside sshd but have added a workaround, and that more frequent releases will follow because AI tools are surfacing bugs quickly. This continues a busy run of SSH fixes, including OpenSSH 10.6’s plaintext-recovery patches and the earlier OpenSSH GSSAPI flaw that crashes SSH child processes.
Administrators running musl-based systems should upgrade OpenSSH to version 10.6p2 immediately, using apk upgrade openssh on Alpine.
They should then restart sshd, because the package update does not restart the running daemon. Teams that cannot patch right away should disable password logins by setting PasswordAuthentication no in a drop-in file such as /etc/ssh/sshd_config.d/00-no-passwords.conf, then restarting the service.
Defenders should also search authentication logs for “Accepted password” entries tied to accounts that have no password, since these indicate a successful bypass.
Running the researcher’s check.sh script on musl hosts is a useful extra check, because CVE-based scanners may miss this flaw. Anyone who finds such an entry should treat the host as compromised: rotate keys and credentials, and review the host for persistence. Alpine has published fixed packages for releases 3.16 through 3.24 and edge.
Give your SOC the alert context to stops incidents quickly. Integrate Threat Intel from 16K SOCs.
