OpenSSH Password Bypass CVE-2026-123158 Exploited on Alpine

An OpenSSH password bypass tracked as CVE-2026-123158 lets a remote attacker log in to accounts that have no password on Alpine Linux and other musl-based systems running sshd without PAM. OpenSSH 10.6p2 and patched Alpine packages shipped on November 5, and threat intelligence firm Previdian logged exploit attempts less than nine hours after the CVE was published. Update openssh and restart sshd now, or set PasswordAuthentication no until you can.

How the OpenSSH password bypass came to light

Özgün Kültekin of Wakefield reported the flaw to the OpenSSH project, which released 10.6p2 about a day later. In a notice to the openssh-unix-dev list, Damien Miller told operators of affected systems to set PasswordAuthentication=no or disable SSH immediately. The notice also explained the speed: the project now treats long embargoes as a risk because AI agents have repeatedly rediscovered bugs within hours.

Alpine published its own advisory the same day, with fixed packages for every branch back to 3.16. That advisory was written before a CVE existed, so older references to this bug may carry no identifier. The researcher calls it "sshole" and has published the background at sshhole.com.

The CVE record scores it CVSS 8.1 (AV:N/AC:H/PR:N/UI:N) with CWE-394. Do not let the high attack complexity rating slow you down: Alpine says the bypass takes one connection, works every time and needs no retries.

Who is affected

A host is exposed only when all of these are true:

It runs Linux with musl libc. Alpine is the common case. The researcher also names OpenWrt, Buildroot and Yocto.
sshd does not use PAM. Alpine's standard openssh-server package is built without it, and openssh-server-pam with UsePAM no is affected too.
PasswordAuthentication is yes, which is the OpenSSH default.
At least one account has * as its password field. See what the shadow password field values mean for why that is so common.
At least one other local account has a real $5$ or $6$ password hash.

The accounts at risk are the ones admins assume are safe: key-only users created without a password, and directory users arriving through musl-nscd with no shadow entry. Root has shipped as * in Alpine base images since about 3.16, but the default PermitRootLogin prohibit-password protects it unless someone set PermitRootLogin yes. That protection is worth little if another reachable account can become root.

Official tiny-cloud images are the sharpest example. Images from 3.18.11 through 3.24.3 ship an alpine user with a * field and passwordless doas. Alpine says they are safe on first boot, then become exploitable once any $6$ hash exists on the machine, for example after an admin sets a console password. An attacker then gets a shell as alpine and can become root.

Not affected: systems on glibc, including Debian, Ubuntu and Fedora; setups that authenticate through PAM; Dropbear; OpenBSD; containers that do not run sshd; hosts with PasswordAuthentication no; and images configured through cloud-init, which writes that setting. Locked accounts with ! in the field are also out of scope. Why musl vs glibc security differences affect patching covers how to sort a mixed fleet.

Technical analysis

The bug sits where three old decisions meet. In 2012, musl changed crypt() to return * on failure rather than NULL, and its SHA-512 code began refusing keys over 256 bytes. In 2016, the fix for the CVE-2016-6210 timing leak made sshd borrow another account's salt when the target account has no usable hash, so that it could spend the same time hashing.

Without PAM, sshd compares the crypt() output to the stored field. An over-long password makes musl's crypt() fail and return *. For an account whose stored field is also *, the strings match and the login succeeds.

Sources differ slightly on the password length: the CVE record says 256 to 1024 characters, while Alpine and the researcher say 257 to 1024 bytes. PAM builds never reach this comparison for a * account, and glibc does not return the same string. Kültekin reports running about 17,600 unusual logins against builds in many combinations, and only musl without PAM accepted any it should have refused.

OpenSSH considers the root cause to be outside its own code, so 10.6p2 is a workaround in sshd. Alpine's stable branches carry a patch for the same problem.

Exploitation status

Treat this as exploited, at low volume so far. Previdian's public page records 8 attempts from one IP address in Japan, all on a single sensor, with first observation at 00:05 UTC on November 6. Previdian's Dewhurst told Help Net Security that the firm confirmed root access on a honeypot running real Alpine and OpenSSH. The source, 89.116.89[.]18, then ran id, uname and hostname over non-interactive sessions. Previdian's public page does not itself show the outcome of the attempts.

CISA has not added CVE-2026-123158 to its KEV catalog as of this writing. Public proof-of-concept code exists, and Previdian labels the repositories it tracks as unverified and warns they could contain malware. Keep them off production and admin workstations.

What to do now

First, update and restart. Upgrading the package does not replace the running daemon, so the old binary keeps accepting connections until you restart it.

apk upgrade -U -a
rc-service sshd restart

Check the installed version against Alpine's fixed list, because stable branches backport the patch and will not report 10.6:

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

If you cannot update yet, turn password logins off and confirm the running configuration reports passwordauthentication no. Test key login first and keep your session open: our guide on how to disable SSH password authentication safely has the full sequence and rollback.

Then look for signs of use. On exposed machines, search /var/log/messages for sshd lines reading Accepted password for that name an account with no password, such as alpine, root or a key-only user. Review doas use, recently created users and files, and changes to authorized keys. Alpine's guidance is direct: if you cannot rule out a login, treat the machine as compromised.

Do not forget appliances and embedded builds. OpenWrt, Buildroot and Yocto systems will not get Alpine's packages, so check each with its vendor or build owner, and disable password logins in the meantime.

What to watch next

Watch for a KEV listing, which would set a federal deadline, and for reports of scanning beyond a single source. Usernames such as alpine and root are predictable, so internet-facing hosts need no prior reconnaissance beyond finding an open SSH port. Also watch for advisories from firmware makers building on musl, since none of the sources reviewed here lists a vendor fix beyond Alpine's packages.