On 5 November 2026 the OpenSSH project shipped an emergency release, OpenSSH 10.6p2, to close a password authentication bypass. The researcher who found it, Özgün Kültekin of Wakefield, named it sshole. It is tracked as CVE-2026-123158 and scored 8.1 (high) on CVSS 3.1. In plain terms: on some Linux systems, an attacker can log into an account that has no password at all by typing a very long password. Any long password works.
Most servers are not affected. The ones that are tend to be small and quiet: Alpine containers, cloud VMs and embedded boxes, the kind of machine nobody logs into often enough to notice a stranger. Below is how the bug works, who it hits, and what to do about it.
How the bypass works
The bug only appears when three old, separately reasonable decisions meet.
- The asterisk convention. On Unix, an account that should never log in with a password stores
*in/etc/shadowinstead of a password hash. Since no real password hashes to*, the account can never match. - musl’s error value (2012). musl is the small C library behind Alpine Linux and many embedded systems. Its
crypt()function refuses SHA-256 and SHA-512 passwords longer than 256 bytes, a cap meant to prevent denial of service. When it refuses, it returns the string*to signal the error. - OpenSSH’s timing fix (2016). To fix a username-enumeration bug (CVE-2016-6210), OpenSSH started hashing every submitted password, even for accounts with no usable hash, so that response times would not reveal which accounts exist. For those accounts it borrows the salt of another account’s real hash.
Put those together. An attacker picks an account whose shadow entry is * and sends a password longer than 256 bytes. sshd hashes it with the borrowed salt, musl gives up and returns *, and sshd compares that * with the stored *. They match, so sshd lets the attacker in. Alpine’s advisory says it takes one connection and works every time. Reports put the working password length at 257 to 1,024 bytes.
OpenSSH says the root cause is outside sshd, but that sshd is where the bug can be exploited and where it can be stopped, so 10.6p2 refuses a match when the stored field is too short to be a real hash. The researcher found it by having AI agents run about 17,600 logins against many builds of glibc, musl, PAM and plain shadow authentication. Every build gave the same answer for every login except one: musl without PAM.
Who is affected
All of the following have to be true:
- OpenSSH (not Dropbear) running on a musl-based Linux system. Alpine is the main example. OpenWrt, Buildroot and Yocto builds have also been named, and so have the many Docker images built on Alpine.
- PAM is not in use. Alpine’s standard
openssh-serverpackage is built without PAM. Theopenssh-server-pampackage withUsePAM yesis not affected. - Password authentication is on. That is OpenSSH’s default.
- At least one account has
*as its password field, and at least one other local account has a real SHA-256 or SHA-512 password ($5$or$6$). Alpine’s advisory says one user with a password is enough.
The * accounts are common. They include root on Alpine since about 3.16, deploy users that log in only with keys, and directory users looked up through musl-nscd. Accounts locked with ! are not affected.
Root is protected by OpenSSH’s default PermitRootLogin prohibit-password unless an admin has changed it to yes. But any other account that can become root still opens a path to root. The worst case is Alpine’s official AWS and Azure images (tiny-cloud, 3.18.11 through 3.24.3). Their default alpine user has * and passwordless doas. They are safe on first boot, but once someone sets a password on any account, even just for console access, anyone who can reach port 22 can get root.
Not affected: glibc distributions such as Debian, Ubuntu, Fedora and RHEL, anything authenticating through PAM, Dropbear, and OpenBSD.
Is it being exploited?
Reports from the first days disagree, so here is who said what:
- Public proof-of-concept code was on GitHub the same day the bug was disclosed.
- Threat intelligence firm Previdian said its first exploitation attempt arrived less than nine hours after the CVE was published, and that an attacker got root on one of its Alpine honeypots and then ran basic reconnaissance commands.
- GreyNoise, as reported by Ciphers Security, later counted several intrusions on its sensors. In those, attackers added SSH keys for root and
alpine, read/etc/shadow, added init scripts, started a second sshd on port 2222, and in one case installed a Python remote-control implant. - Other outlets said on 6 November that exploitation in the wild had not been confirmed, and CISA had not added the CVE to its Known Exploited Vulnerabilities catalogue as of that day.
A one-line exploit, a public PoC and an internet full of forgotten Alpine boxes is enough to assume it is being exploited, whatever the official status.
What to do now
1. Patch, then restart sshd. Installing the update does not restart the running daemon, and the old binary keeps accepting logins until you restart it. On Alpine:
apk upgrade -U -a
rc-service sshd restartThe fixed Alpine packages are openssh 10.6_p2-r0 on edge, 10.3_p1-r2 on 3.24, 10.2_p1-r1 on 3.23, 10.0_p1-r11 on 3.22 and 9.9_p2-r1 on 3.21, with patched builds back to 3.16. Images from Alpine 3.21.10, 3.22.8, 3.23.8 and 3.24.4 onward include the fix. For containers, rebuild from a fresh base image rather than patching running ones.
2. If you cannot patch right away, turn off password logins. OpenSSH’s Damien Miller advised disabling password authentication, or SSH entirely, on these systems immediately. On Alpine 3.19 and later:
mkdir -p /etc/ssh/sshd_config.d
echo 'PasswordAuthentication no' > /etc/ssh/sshd_config.d/00-no-passwords.conf
sshd -t && rc-service sshd restart
sshd -T | grep -i passwordauthenticationThe last line should print passwordauthentication no. On older releases, set PasswordAuthentication no in /etc/ssh/sshd_config itself. Keep your current session open until you have confirmed you can still log in with your key from a new one.
3. Check whether you were exposed. As root, list the accounts with * and the accounts with real password hashes:
awk -F: '$2=="*" {print $1}' /etc/shadow
awk -F: '$2 ~ /^\$[56]\$/ {print $1}' /etc/shadowIf both lists have entries, password authentication was on and you were running an unpatched musl build without PAM, the machine was open. Search the logs for successful password logins to accounts that have no password:
grep 'Accepted password for' /var/log/messagesA line naming alpine, root or a key-only user means someone got in. The log does not record password length, so there is no cleaner signal than that.
4. If you cannot rule out a login, treat the machine as compromised. Look for new or changed authorized_keys files, new init scripts, unexpected users, an extra sshd listening on another port, and recent doas use. Then rebuild the machine and rotate every key and secret it held. Removing what you find and carrying on is not enough.
The bigger lesson
None of the three pieces was wrong on its own. A libc returning * on error is sensible. Hashing every password to defeat a timing leak is sensible. Using * to mean “no password” is a convention from 1980. The bug sat in the gap between them for about ten years until an automated search tried enough combinations. The OpenSSH team noted in this release that bugs found by AI are now being independently rediscovered by others, which is why it is releasing more often. Expect more bugs like this, found faster, and expect the time between disclosure and exploitation to keep shrinking.
The defences that held this time were the dull ones: SSH keys instead of passwords, no direct root login, and a patch cycle short enough to close the gap within a day. If your servers accept password logins, this is a good week to stop.
Sources: the OpenSSH 10.6p2 release notes, Alpine Linux’s 5 November 2026 security advisory, the researcher’s write-up at sshhole.com, and reporting by BleepingComputer, Help Net Security, The Hacker News and Ciphers Security.
Questions or corrections about this post? pg-355-ecb4b5@nomadscrolls.net