OpenSSH shipped an emergency release on 5 November 2026. Version 10.6p2 closes a password authentication bypass in sshd, tracked as CVE-2026-123158 with a CVSS score of 8.1, that lets a remote attacker log in to accounts that were never supposed to accept a password at all. The attacker only needs a username and a password between 257 and 1,024 bytes long.

The bug lives in the gap between two projects, and it has been there since 2016. That year, OpenSSH fixed a username-enumeration flaw (CVE-2016-6210) by making sshd always perform a hash comparison, even for accounts with no password. An account whose /etc/shadow field is a single * has no salt, so sshd borrows one from another account. But musl, the C library Alpine uses instead of glibc, refuses to hash passwords longer than 256 bytes for $5$ and $6$ hashes and returns * instead of the NULL POSIX requires. Send 257 bytes or more, musl returns *, the stored field is *, and sshd opens the door.

Who is actually exposed

All four must hold on the same server, which is why most Linux servers are fine:

  • sshd is built against musl libc. Alpine Linux is the well-known case, and the base of countless Docker images, though only images that run sshd are exposed.
  • sshd checks passwords without PAM. Alpine's default openssh-server package is compiled without PAM, and a build with PAM compiled in but UsePAM no is exposed too.
  • PasswordAuthentication is enabled, which is the upstream default.
  • The target account has exactly * as its password field: key-only service accounts, LDAP-backed users, locked accounts. The accounts admins hardened on purpose are the ones this bug opens.

Debian, Ubuntu, Fedora, Red Hat Enterprise Linux, and every other glibc-based distribution are not affected, and neither is any system where sshd authenticates through PAM. OpenWrt, Buildroot, and Yocto builds on musl should check rather than assume they are safe.

The flaw was reported by Özgün Kültekin of Wakefield, who published the details under the nickname "sshole". His write-up says AI agents ran about 17,600 authentication tests before the bug surfaced. That fits a pattern OpenSSH flagged in the 10.6 release notes: AI tools are finding real bugs now, so the team ships fixes faster. Report to release took about a day, with no embargo at all.

As of 6 November, neither OpenSSH nor Alpine had reported attacks in the wild, and the flaw was not in CISA's Known Exploited Vulnerabilities catalogue. Do not let that reassure you: the proof of concept is public and Alpine is the default base image for a huge share of containers.

The 60-second exposure check

On Alpine or any musl-based system with sshd, check before you patch. Confirm the OS and package, then list accounts whose password field is a bare *:

BASH
cat /etc/os-release | head -2
apk info -v openssh-server
sudo awk -F: '$2 == "*" {print $1}' /etc/shadow

Then check whether sshd uses PAM and whether password logins are on:

BASH
sudo sshd -T | grep -iE 'usepam|passwordauthentication'

If usepam is no, passwordauthentication is yes, and the awk output lists real accounts, you are exposed. If usepam is yes, the broken code path is never reached.

Patch it, then restart sshd

Alpine shipped fixed packages the same day: edge gets 10.6_p2-r0, and releases 3.19 through 3.24 get the same fix backported (10.3_p1-r2 on 3.24 down to 9.6_p1-r3 on 3.19). Check the package revision, not the upstream version number.

On Alpine, the patch is one command:

BASH
apk update && apk upgrade openssh-server

Then do the step everyone forgets: restart the daemon. Upgrading the package does not restart the running sshd:

BASH
rc-service sshd restart
rc-service sshd status

In a container, restart the container or the sshd process inside it, then confirm the new package version with apk info -v openssh-server.

If you cannot patch right now, the OpenSSH maintainer's advice was blunt: set PasswordAuthentication no in sshd_config, or disable SSH entirely, immediately. That is also the right permanent posture: key-only authentication removes an entire class of password attacks, and our SSH hardening audit covers the rest.

What the fix changes

The 10.6p2 workaround is small and surgical: sshd now refuses a password match whenever the stored password field is shorter than four characters, whatever crypt() returns. A one-character * can never authenticate again. OpenSSH calls it a workaround because the team puts the root cause outside sshd, in musl's * return; the musl maintainer calls it an erroneous use by the caller. Whose bug it is will be argued for a while; the patch is out, and that is what matters.

Two lessons. The accounts you lock down hardest deserve the most scrutiny, because a bypass aimed at * fields hits exactly the accounts you assumed were safest. And defence in depth is not a slogan: PAM, key-only logins, and a firewall in front of port 22 each independently break this attack. Patch, restart, then check which layers you are still missing.

Sources