CVE-2026-123158
An authentication bypass in OpenSSH's sshd on musl-based Linux without PAM, including Alpine's default package, lets attackers log in to accounts with no password set.
Last reviewed
Updates
OpenSSH released 10.6p2, Alpine published fixed packages back to 3.16, and CVE-2026-123158 was assigned.
Overview
Details
When sshd is built without PAM, it checks a password by hashing the attempt with the C library's crypt() and comparing the result to the account's stored password field. Accounts with no password set store * in that field, which normally matches nothing.
musl's crypt() returns the string * as an error value when the password is longer than 256 bytes. sshd compares that * to the stored *, finds a match and accepts the login. The attack needs one other account on the machine with a $5$ or $6$ password hash, because sshd borrows its salt. One such account makes every account without a password reachable.
The flaw dates to 2016 and was reported by Özgün Kültekin of Wakefield. OpenSSH 10.6p2 adds a workaround in sshd; OpenSSH considers the root cause to be outside sshd. Alpine backported the fix to every branch from 3.16, so a lower OpenSSH version number does not mean a host is still vulnerable.
Alpine's official tiny-cloud images from 3.18.11 through 3.24.3 ship an alpine user with no password and passwordless doas. They are safe on first boot but become exploitable once any $6$ hash exists on the machine, for example after an admin sets a console password. An attacker can then log in as alpine and use doas to become root, even though root itself is reachable only if PermitRootLogin yes is set.
Not affected: glibc systems, Alpine's openssh-server-pam package with UsePAM yes, and accounts locked with !. According to Alpine, cloud images configured through cloud-init are not affected either, because cloud-init writes PasswordAuthentication no unless user-data sets ssh_pwauth: true.
Risk
With password logins enabled, an unauthenticated attacker can log in to passwordless accounts if another account has a $5$ or $6$ hash. Neither OpenSSH nor Alpine had reported exploitation as of November 6.
Affected deployments
Hosts running OpenSSH sshd before 10.6p2 and without their distribution's backported fix, on musl-based Linux such as Alpine (the researcher also lists OpenWrt, Buildroot and Yocto builds running OpenSSH) without PAM and with PasswordAuthentication enabled. Targets are accounts whose password field is * and directory-service users via musl-nscd, which have no shadow entry.
Recommended action
Update OpenSSH to 10.6p2 or your distribution's fixed package, then restart sshd. If you cannot update yet, set PasswordAuthentication no and restart sshd.
Find hosts running sshd on musl-based Linux, including Alpine VMs, cloud images, appliances and containers that run sshd. Check whether sshd uses PAM and whether PasswordAuthentication is enabled, including inside Match blocks in sshd_config and its drop-in files.
Update OpenSSH to 10.6p2 or your distribution's fixed package. On Alpine, run apk upgrade -U -a, then compare the version shown by apk list -I 'openssh*' with the advisory's fixed version for your branch. Alpine's fixed packages keep older version numbers, so sshd -V alone does not show the fix.
Restart sshd (rc-service sshd restart on Alpine). Upgrading the package does not replace the running daemon.
If you cannot update yet, set PasswordAuthentication no, including in any Match block that enables it. Check the configuration with sshd -t, restart sshd and confirm that sshd -T | grep -i passwordauthentication shows PasswordAuthentication set to no; for Match blocks, test with sshd -T -C user=…,host=…,addr=…. Keep an existing key-based session open while you test.
Check /var/log/messages for sshd lines reading Accepted password for an account with no password, such as alpine, root, a key-only user or a directory-service user. If you find one or cannot rule out a login, treat the host as compromised and review doas use, new users, changed files and authorized_keys.
Use this prompt with an agent that can inspect your infrastructure.
Assess whether the infrastructure available to you is affected by CVE-2026-123158 (*sshole), the OpenSSH password authentication bypass on musl-based Linux without PAM. Perform a read-only assessment within your authorized access. Do not attempt logins with long passwords, change sshd configuration or restart services. 1. Verify the current CVE record at https://www.cve.org/CVERecord?id=CVE-2026-123158, the OpenSSH 10.6p2 release notes at https://www.openssh.org/releasenotes.html#10.6p2 and the Alpine advisory at https://alpinelinux.org/posts/2026-11-05-openssh-password-authentication-bypass/. Establish affected and fixed versions, including Alpine's backported package versions. Cite sources and retrieval dates. 2. Inventory accessible hosts, VMs, cloud images, appliances and containers that run sshd. For each, record the C library (musl or glibc), the installed openssh package and version, whether the running sshd started after the package was installed, whether it uses PAM (openssh-server vs openssh-server-pam and UsePAM), and the effective PasswordAuthentication value from sshd -T. sshd -T without -C ignores Match blocks, so also inspect Match blocks in sshd_config and its drop-ins, or test them with sshd -T -C. Get the installed package release with apk list -I 'openssh*' on Alpine and compare it with the advisory's fixed version, not the version sshd -V prints. 3. Where you have access, list accounts whose /etc/shadow password field is exactly * and whether any account has a $5$ or $6$ hash. Do not print hashes; record only the field type. Note directory-service users without shadow entries, and accounts with passwordless doas or sudo. 4. Search /var/log/messages or the journal for sshd 'Accepted password for' entries on accounts with no password, and note any found. Return a concise summary and a table: host | libc | openssh package/version | sshd restarted after update | PAM | PasswordAuthentication | * and $5$/$6$ accounts present | assessment (affected, fixed, not applicable or unknown) | evidence | next action. Separate an installed fix from a running fix, and patch status from evidence of compromise. List hosts you could not assess and the access needed. Find more information and resources at https://radar.cloudflare.com/security/zero-wire/sshole
Cloudflare coverage
Product coverage
This attack targets SSH, not HTTP, so WAF rules do not apply.
Evidence and sources
CVE record
Rated High, CVSS 3.1 8.1. CISA's assessment lists a public proof of concept and does not consider the attack automatable.
Vendor advisories
Alpine lists the conditions for exposure, fixed package versions per branch, cloud image impact and how to check for compromise.
cloud-init configuration
cloud-init's default config sets ssh_pwauth: false for Alpine, so it writes PasswordAuthentication no unless user-data sets ssh_pwauth: true.
Original research
The researcher's check script compares sshd's version number, so it can report Alpine's backported fixed packages as exposed.