What happened
On November 5, 2026, the OpenSSH developers shipped an urgent security release, OpenSSH 10.6p2. It addresses CVE-2026-123158, a flaw its discoverer Özgün Kültekin of Wakefield nicknamed “sshole”. It affects the SSH server sshd on Linux systems that use the musl C library and do not check passwords through PAM. The best-known such system is Alpine Linux, which published its own advisory and fixed packages the same day.
According to Alpine Linux, an attacker who can reach your SSH port can, under certain conditions, log in without knowing any password. It takes a single connection and, Alpine says, works every time. OpenSSH developer Damien Miller called it a critical vulnerability and told admins of affected systems to disable password logins or SSH altogether immediately.
Threat intelligence firm Previdian told Help Net Security that its sensors saw the first exploitation attempt less than nine hours after the flaw was published, and that it confirmed successful root access on one of its honeypots. So far it has counted eight attempts, all from a single address. CISA has not added the flaw to its KEV catalog of exploited vulnerabilities, and the EU vulnerability database EUVD does not list it as exploited yet.
Why it is dangerous
This is an “unexpected return value” bug (CWE-394). To check a password, sshd hashes what you typed and compares the result with the value stored in /etc/shadow. Accounts without a password store just a * there instead of a hash. When the password is too long, musl’s crypt() function fails and returns * as its error marker, so the result matches the stored value and the server lets the user in.
Picture a doorman who compares a key’s imprint against a list. For people who have no key, the list just says “X”. When the reader breaks, it also prints “X”, so the doorman sees a match and opens the door. According to Alpine, the attacker needs the name of an account without a password, and the machine must have at least one other account with a password set.
The attack works over the network and needs no login and no user interaction. The attacker gets a shell as the targeted account. If that account can become root, for example through doas, the whole server is taken over and can be used as a stepping stone into the rest of your network.
- CVSS 8.1 out of 10 (high severity): the score was assigned by MITRE. CVSS is the standard severity scale. It is not rated at the maximum mainly because the attack depends on specific configuration conditions.
- CISA KEV: the catalog of vulnerabilities that the US agency CISA has confirmed as exploited. This flaw is not in it yet.
- EPSS 0.98% (November 6, 2026): an estimate of the probability that the flaw will be exploited in the next 30 days. That is higher than for roughly 62% of known flaws. For a freshly disclosed bug, this estimate still changes quickly.
Who is affected
The flaw affects OpenSSH before 10.6p2 on Linux with musl libc and no PAM. According to the OpenSSH developers, it does not affect non-Linux systems, glibc-based Linux or systems that check passwords through PAM. The researcher who found it confirms Debian, Ubuntu, Fedora, Dropbear and OpenBSD are safe, and suggests checking OpenWrt, Buildroot, Yocto and many Docker images.
On Alpine Linux, Alpine says you are affected if all of the following are true:
- you run
openssh-server(built without PAM), oropenssh-server-pamwithUsePAM no, PasswordAuthenticationisyes, which is the default,- an account has
*instead of a password in/etc/shadow:root(since about Alpine 3.16, though the defaultPermitRootLogin prohibit-passwordprotects it), key-only users, directory users via musl-nscd, or thealpineuser in tiny-cloud images, - at least one local account has a
$5$or$6$password hash.
Alpine lists releases 3.21 through 3.24 and edge as affected, plus the older 3.16 to 3.20. The tiny-cloud images from 3.18.11 through 3.24.3 ship an alpine user with passwordless doas, which is a path to root. They become vulnerable as soon as any $6$ hash appears on the machine.
Not affected: containers that do not run sshd, systems with PasswordAuthentication no, openssh-server-pam with UsePAM yes, locked accounts with ! in /etc/shadow, and images configured by cloud-init, which turns password logins off.
How to check if you are affected
All commands below only read data and change nothing. Run them as root. First, find your Alpine release and the installed OpenSSH package version:
cat /etc/alpine-release
apk info -v 2>/dev/null | grep opensshCompare the package version with the list in the fix section. Then check whether sshd is running and how it is configured:
rc-service sshd status
sshd -T | grep -iE 'passwordauthentication|usepam|permitrootlogin'Finally, list which accounts have no password (*) and which have a $5$ or $6$ hash. The commands print account names only:
grep -E '^[^:]+:\*:' /etc/shadow | cut -d: -f1
grep -E '^[^:]+:\$[56]\$' /etc/shadow | cut -d: -f1If you have an older package, sshd is running, password logins are on and both lists contain at least one account, the server is vulnerable.
How to fix it
The fix is OpenSSH 10.6p2. Alpine has published fixed packages for every branch from 3.16 to edge, including older releases that no longer get regular updates. Alpine 3.21.10, 3.22.8, 3.23.8 and 3.24.4 also ship the fixed package. Fixed openssh package versions by branch:
- edge: 10.6_p2-r0
- 3.24: 10.3_p1-r2
- 3.23: 10.2_p1-r1
- 3.22: 10.0_p1-r11
- 3.21: 9.9_p2-r1
- 3.20: 9.7_p1-r6
- 3.19: 9.6_p1-r3
- 3.18: 9.3_p2-r4
- 3.17: 9.1_p1-r7
- 3.16: 9.0_p1-r6
- 1. Start with servers whose SSH port is reachable from the internet.
- 2. Update the packages and restart
sshd(commands below). Upgrading alone does not replace the running process, so the old binary would keep accepting connections. - 3. Verify the version with the commands from the check section.
- 4. For cloud instances built from tiny-cloud images older than 3.21.10, 3.22.8, 3.23.8 and 3.24.4, update every running instance.
apk upgrade -U -a
rc-service sshd restartIf you cannot update right away, both Alpine and the OpenSSH developers advise at least setting PasswordAuthentication no in the sshd configuration and restarting it. OpenSSH developer Damien Miller also mentions disabling SSH on affected machines entirely. Before the change, make sure key-based login works and keep your current session open until you have tested a new one. Check the configuration with sshd -t before restarting. If you do not need SSH passwords, we recommend keeping them off even after updating.
What if you may already be compromised
Alpine advises searching /var/log/messages for sshd lines reading Accepted password for that name accounts without a password, such as alpine, root or key-only users. Such an entry is a serious sign of a break-in. The commands below also search older and compressed logs:
grep -h "Accepted password for" /var/log/messages /var/log/messages.[0-9] 2>/dev/null
for f in /var/log/messages*.gz; do [ -e "$f" ] && gunzip -c "$f" | grep "Accepted password for"; done- Review
doasusage and recently created users. - Look for new files and unknown keys in
authorized_keysfiles. - According to Previdian, the attacker came from a single Japan-based address, which the firm shared with Help Net Security. It used oversized passwords and ran reconnaissance commands
id,unameandhostnamein non-interactive SSH sessions. Watch for logins from unfamiliar addresses.
If you cannot rule out a login, Alpine says to treat the machine as compromised. Disconnect it from the network, preserve the logs and bring in an incident response specialist before reinstalling. Do not run the “proof-of-concept” exploits posted on GitHub: Previdian warns they are unverified and could contain malware.