A password made of 300 repeated letters should never open a server. On Alpine Linux, it could. The OpenSSH password bypass disclosed on Nov. 5 lets anyone who can reach an exposed SSH port log in to accounts that were never given a password, and a threat-intelligence firm says attackers were trying it within nine hours. The fix is already out. The harder question for most teams is whether any of their machines were actually exposed, because the bug only works when five separate conditions line up.
This piece walks through those five conditions in the order an administrator can check them. It also covers what the early attack data does and does not show, and why the package count in a scanner report is a poor guide to real risk.
How a failed hash became a valid login
The flaw sits in the gap between two pieces of software that each behave reasonably on their own. When sshd is built without PAM, it checks a password by running it through the C library’s crypt() function and comparing the output with the stored password field. For accounts whose stored field is too short to hold a salt, such as a lone *, sshd borrows the salt of another real account. That behavior dates to a 2016 fix for a username-timing leak, CVE-2016-6210.
Meanwhile, the musl C library, which Alpine uses instead of glibc, has returned the literal string * when hashing fails since 2012. Its SHA-512 code fails on any password longer than 256 bytes. As a result, a password between 257 and 1,024 bytes “hashes” to *, the stored field is also *, and the comparison passes. Alpine’s security advisory puts it bluntly: the attack “takes one connection, works every time, and needs no retries.”
The bug was reported to OpenSSH on Nov. 4 by Özgün Kültekin of Wakefield, according to cloud security firm Upwind. The OpenSSH 10.6p2 release notes call the fix “a critical security workaround” and say the project considers the root cause to be “outside sshd,” though it can be exploited through it. The flaw is now tracked as CVE-2026-123158 with a CVSS score of 8.1, SecurityWeek reported. Kültekin has nicknamed it “sshole.”
Five conditions decide whether the OpenSSH password bypass works
Every one of the following must be true on the same machine. If any single item fails, that machine is not exposed to this particular flaw.
1. The system runs musl, not glibc
Alpine is the main case. Kültekin also lists OpenWrt, Buildroot and Yocto builds, along with other musl distributions, in the project’s GitHub notes. Debian, Ubuntu, Fedora and other glibc systems are not affected, and neither are OpenBSD, FreeBSD or macOS.
2. sshd checks passwords without PAM
Alpine’s standard openssh-server package is built without PAM, so it is in scope by default. By contrast, openssh-server-pam is safe with UsePAM yes but becomes vulnerable if that setting is switched to no.
3. Password logins are switched on
PasswordAuthentication yes is the OpenSSH default. Running sshd -T | grep -i passwordauthentication shows the effective value, including any drop-in files. Cloud images configured through cloud-init are not affected, Alpine says, because cloud-init writes PasswordAuthentication no.
4. At least one account has a bare asterisk for a password
This is more common than it sounds. Alpine has shipped root:* in its base image since roughly version 3.16. Key-only users created with adduser and no password also get a *, as do directory-service users who arrive through musl-nscd. However, accounts locked with ! are not affected. Root also has a second guard: OpenSSH’s default PermitRootLogin prohibit-password keeps it out of reach unless an administrator changed it to yes.
5. Some other account has a real password hash
The attack borrows a salt, so it needs at least one local account with a $5$ or $6$ hash. One is enough. In Alpine’s words, a single user with a password “makes every account without one reachable.”
The cloud-image trap inside the OpenSSH password bypass
Conditions four and five interact badly on Alpine’s official tiny-cloud images. The qcow2, VHD and AMI builds from 3.18.11 through 3.24.3 ship an alpine user with a * password field and passwordless doas. On first boot, no account has a real hash, so the machine is safe.
That changes the moment someone sets a console password or user-data adds a user with a hashed password. From then on, an attacker can log in as alpine and use doas to become root. In other words, a routine step taken for emergency console access can quietly complete the attack chain. Images built from 3.21.10, 3.22.8, 3.23.8, 3.24.4 and later include the fixed package. Older instances need updating in place.
What the first OpenSSH password bypass attacks show
Threat-intelligence firm Previdian told Help Net Security that its first observed attempt arrived “less than nine hours after CVE publication.” Founder Ryan Dewhurst said the company confirmed root access on one of its own honeypots running real Alpine Linux and OpenSSH. The attacker used oversized passwords and then ran basic reconnaissance commands such as id, uname and hostname.
Those numbers are small. At the time, Previdian counted eight attempts, all from a single Japan-based address and caught by one sensor. A honeypot is also built to be found. So the data shows that someone weaponized the flaw fast, not that real servers were broken into at scale. Still, Alpine’s own description of the attack as a one-shot, no-retry login means scanning for it is cheap. The same pattern appeared in our earlier look at how attackers turned a fake job interview into the Binance theft: the gap between disclosure and abuse keeps shrinking.
Why scanner counts overstate exposure
Upwind’s sweep of the environments it monitors suggests most alerts will be noise. About 98 environments shipped Alpine’s openssh-server package, but most were debug, CI or VM images that never start sshd. Of 471 groups of containers actually running sshd, 331 were glibc and not affected, 38 were musl and 102 could not be classified.
That last bucket matters. Upwind notes that whether the port is reachable, the effective sshd configuration and whether a given login was a bypass cannot all be confirmed from telemetry. For that reason, a quick look at running processes and the effective configuration beats a package inventory. Kültekin’s repository also offers a check script that reports which of the five conditions is missing on a given host, though administrators should read any third-party script before running it as root.
Closing the OpenSSH password bypass on your own servers
The fixed Alpine openssh packages differ by branch, which trips up anyone looking only for version 10.6p2. Alpine’s table lists them as follows:
- edge: 10.6_p2-r0
- 3.24: 10.3_p1-r2 and 3.23: 10.2_p1-r1
- 3.22: 10.0_p1-r11 and 3.21: 9.9_p2-r1
- 3.20: 9.7_p1-r6 and 3.19: 9.6_p1-r3
- 3.18: 9.3_p2-r4, 3.17: 9.1_p1-r7 and 3.16: 9.0_p1-r6
After upgrading, restart the daemon with rc-service sshd restart. Upgrading the package does not replace a running sshd, so a server that was never restarted keeps accepting the attack. If an upgrade has to wait, setting PasswordAuthentication no and restarting closes the hole completely. First confirm that key-based login works and keep an existing session open while testing.
Finally, check whether anyone got in before the patch. Alpine advises searching /var/log/messages for sshd lines reading Accepted password for an account that has no password, such as alpine, root or a key-only user. Then review doas use, recently created users, new files and changes to authorized keys. If a login cannot be ruled out, Alpine says to treat the machine as compromised.
A warning about faster bug discovery
The release notes for OpenSSH 10.6 and 10.6p2 carry an unusual note. The project says it has received “a large number of security bug reports,” many found with AI tools, and that some bugs found by AI were later discovered again by different researchers. It concludes that adversaries who never report bugs “are likely to be able to discover these bugs too,” so OpenSSH will ship more frequent releases rather than batching fixes. AI agents are already being pointed at real systems in authorised tests, as our look at what went wrong in the Gemini security trials showed.
For administrators, that points to a practical habit as much as a single patch. Small, quiet devices, from routers running OpenWrt to forgotten Alpine containers, tend to be updated least often. Our report on how a hacked air-alert app reached public loudspeakers showed how far a single overlooked system can carry an intrusion. The OpenSSH password bypass will not be the last flaw of its kind. Turning off password logins wherever keys already work removes this whole class of risk, whatever the next disclosure turns out to be.
