What happened
On 5 November 2026 the OpenSSH project released OpenSSH 10.6p2. Its release notes describe a critical security workaround: sshd should "avoid password authentication bypass that is exploitable through sshd(8)" on Linux systems that use the musl C library with PAM disabled. The notes credit Özgün Kültekin of Wakefield for the report, and say the root cause lies outside sshd, although sshd can avoid it.
The flaw is tracked as CVE-2026-123158 and rated CVSS 3.1 8.1 (High), with the vector AV:N/AC:H/PR:N/UI:N: it works over the network and needs no account or user interaction, but it needs a specific setup, which is why the attack complexity is high. Researchers have nicknamed it "sshole". Alpine Linux published fixed openssh packages the same day.
How the bypass works
When musl's crypt() function receives a password longer than 256 bytes, it returns the single character * as an error signal. The glibc version returns nothing (NULL) in that case, which sshd already rejects.
On Alpine, a * in the second field of /etc/shadow is also how an account with no password is marked. So sshd compares the returned * with the stored *, finds them equal, and accepts the login.
An attacker therefore offers a password between 257 and 1024 bytes for an account that has no password. According to the researchers' write-up, sshd borrows the salt from another account that has a SHA-256 or SHA-512 hash, so one such account must also exist. The attacker never needs to know any real password.
Are you affected?
All of the following must be true:
- sshd runs on musl libc without PAM. That is the default
openssh-serverpackage on Alpine, oropenssh-server-pamwithUsePAM no. - Password authentication is enabled. It is the default.
- At least one account has a shadow password field of exactly
*. Locked accounts (!) are not affected. - At least one other local account has a
$5$or$6$password hash.
You are not affected if you use a glibc distribution such as Debian, Ubuntu, Fedora or Red Hat Enterprise Linux, or if sshd authenticates through PAM. Red Hat states that none of its products are affected, because they link OpenSSH against glibc and use PAM by default.
The default PermitRootLogin prohibit-password keeps root out of reach directly. The risk is an account with no password that can reach root another way. The researchers point out that Alpine's official cloud images include a user named alpine with no password and doas rights, which makes them exploitable once any password hash exists.
Containers are exposed only if they actually run sshd with password logins enabled. Most container workloads run no SSH server at all.
Check your systems
On each host, see whether password logins are on and PAM is off. As root:
sshd -T | grep -i -E 'passwordauthentication|usepam'If password authentication is no or PAM is yes, this CVE does not apply. Otherwise list the two kinds of account that make the attack possible:
# accounts with no password
awk -F: '$2 == "*" {print $1}' /etc/shadow
# accounts with a SHA-256 or SHA-512 hash
awk -F: '$2 ~ /^\$[56]\$/ {print $1}' /etc/shadowIf both lists have entries and password logins are enabled, the host was exploitable. For container images, check whether they install openssh-server on Alpine, set a password (for example with chpasswd) and leave password logins on.
Fix it
Update, then restart sshd. A running daemon keeps the old code until it is restarted. On Alpine:
apk upgrade -U -a
rc-service sshd restartAlpine published a fixed openssh package for each supported branch. They keep their older version numbers, so a version-based scanner may still flag a patched host: check Alpine's security advisory for the exact package version of your branch. Elsewhere, move to OpenSSH 10.6p2. Rebuild and redeploy every container image that carries an older openssh package.
If you cannot update yet, turn password authentication off. Before restarting, make sure key-based login works, and keep one session open until you have tested a second one:
# in sshd_config, or a file in sshd_config.d if it is included
PasswordAuthentication nosshd -t # validate the configuration
rc-service sshd restart
sshd -T | grep -i passwordauthenticationCheck Match blocks too, because one of them could switch password logins back on for some users or addresses.
Look for signs of abuse
Search the logs for password logins that succeeded for accounts that have no password. On Alpine the SSH log is in /var/log/messages:
grep "Accepted password" /var/log/messagesA match for an account without a password means the host should be treated as compromised. Then review doas use, new users, recently changed files and authorized_keys entries, and rotate any credentials that were reachable from that host.
Is it being exploited?
As of 5 November 2026, researchers had not reported exploitation in the wild. Public lab setups to reproduce the issue exist, CISA's data lists the exploit status as proof of concept, and the CVE is not in the Known Exploited Vulnerabilities catalogue. That can change quickly for a bug with a public recipe, so treat it as a patch-this-week item for any host in the scope above.
The fix followed the report by about a day: Cycode's analysis notes that the OpenSSH maintainers no longer keep long embargoes, because tools can rediscover a reported bug within hours. That is a reason to keep a current inventory of what runs SSH, and to be able to patch fast. If you are not sure where SSH, Alpine or password logins hide in your cloud, a cloud security review finds them. Our guide to five cloud security fixes that take less than a day covers the habits that make a bug like this a non-event.
Sources: the OpenSSH release notes, the Ethiack research write-up, Red Hat's CVE page and Cycode's analysis. This post reflects them as of 6 November 2026.