OpenSSH CVE-2026-123158 (sshole)

OpenSSH 10.6p2, released on November 5, 2026, fixes a password authentication bypass in sshd, CVE-2026-123158 (nicknamed "sshole"). CISA added it to the Known Exploited Vulnerabilities (KEV) catalog on November 9. It affects sshd running on musl libc without PAM, which means Alpine Linux above all. glibc distributions such as Debian, Ubuntu and RHEL are reported as not affected.

This article is based on the OpenSSH release notes, the Alpine Linux advisory, the NVD/CVE records, CISA KEV and the GitHub commit as of November 10, 2026. Where something could not be confirmed, we say "not stated" or "check the vendor", rather than guess. See also our November 6 vulnerability digest and the November 10 digest.

- What happened: on Linux with musl libc and no PAM, sshd accepts a very long password (about 257 to 1024 characters) for accounts whose password field is "*" (accounts with no password). CVSS 3.1 is 8.1 (High, scored by the CNA, MITRE). CISA added it to KEV on November 9 with a due date of November 12.
- Who is affected: Alpine Linux hosts and VMs that run sshd, plus musl-based embedded Linux such as OpenWrt, Buildroot and Yocto. glibc distributions (Debian, Ubuntu, Fedora), PAM-based setups, Dropbear and OpenBSD are reported as not affected.
- What to do today: (1) inventory Alpine/musl systems that run sshd; (2) update and restart sshd (updating alone does not replace the running daemon); (3) if you cannot update, set PasswordAuthentication no and restart; (4) check logs for password logins you do not recognize.

Alpine says every release it checked (3.16 through 3.24 and edge) is affected, but only when the four conditions below are all met.

Alpine backports the fix, so package versions do not read 10.6p2. Compare against the package versions in the table instead of looking for 10.6p2. Upstream, the fixed release is OpenSSH 10.6p2, and the NVD/CVE records mark versions before 10.6p2 as affected.

On Linux, an account with no password has "*" in the password field of /etc/shadow. Normally "*" means "no password can ever match". On Alpine base images, root has "*" (since Alpine 3.16) so that it can only log in with a key. Users from LDAP and similar sources may also show "*".

Without PAM, sshd hashes the submitted password with crypt() and compares the result with the stored value. musl's crypt() returns "*" on failure, and its SHA-512 scheme rejects passwords over 256 bytes. So a password of 257 bytes or more makes crypt() return "*", which equals the stored "*", and authentication succeeds. This follows Alpine's advisory and the researcher's site, sshhole.com.

sshd also borrows another account's salt for accounts whose stored field is too short to hold one. So at least one account with a $5$ or $6$ hash must exist on the system (Alpine advisory). NVD says passwords of 256 to 1024 characters work, while Alpine says 257 to 1024 bytes, so sources differ by one at the boundary.

The OpenSSH release notes call the fix a "critical security workaround" and consider the root cause to lie outside sshd. From the diff of GitHub commit "avoid password authn bypass", the change appears to add a minimum-length check on the stored hash string; the commit message itself does not explain the mechanism.

According to Alpine, a host is affected only when all four hold.

- sshd is built without PAM (the default for Alpine's openssh-server), or openssh-server-pam is used with UsePAM no
- PasswordAuthentication is yes (the OpenSSH default)
- At least one account has "*" in its password field (root on Alpine base images, key-only users, users from nslcd, winbind or sssd)
- At least one local account has a $5$ or $6$ hash

Alpine lists these as not affected: PasswordAuthentication no, UsePAM yes, accounts locked with "!", systems with no "$"-style hash, and cloud-init images that set PasswordAuthentication no. Medcrypt separately reported reproducing the issue on a stock Yocto image with locked service accounts (oss-security post), so do not assume an embedded device is safe without checking.

NVD records that CISA added the flaw to KEV on November 9, as "OpenBSD OpenSSH Unexpected Status Code or Return Value Vulnerability" (CWE-394), with a due date of November 12. CISA's SSVC assessment reads Exploitation: active, Automatable: no, Technical Impact: total.

Help Net Security (November 6) reported that Previdian saw the first attempt less than nine hours after the CVE was published and confirmed root access on an Alpine honeypot. The eight recorded attempts came from one IP address and ran reconnaissance commands (id, uname, hostname). Public proof-of-concept code exists on GitHub; Previdian warns unverified code may contain malware. Test only in an isolated environment you own.

Run these only on servers you manage. Never send long passwords to systems you do not own; that is unauthorized access.

First, check whether the host is musl-based and which OpenSSH it runs.

If the ldd output mentions musl, it is a musl system (glibc shows libc.so.6). If sshd lives elsewhere, use the result of which sshd. On Alpine, check the installed package version:

Then look at the effective sshd settings (root required). sshd -T is more reliable than reading config files.

If passwordauthentication no is shown, this path is closed. If it is yes, look for accounts with "*" and accounts with $5$/$6$ hashes.

If both lists are non-empty, and PasswordAuthentication is yes with no PAM, treat the host as vulnerable until patched. The researcher's repository (oz9un/sshole) has a check.sh that tests these items; read it before running it and use it only on hosts you manage.

For Docker images, what matters is whether the image runs sshd (IMAGE is the image to inspect).

If sshd is neither installed nor started, the CVE does not apply. For images that bundle sshd, such as bastion or SFTP images, check whether the base is Alpine.

Alpine's advice is to update and restart sshd. Updating alone leaves the old daemon running.

Afterwards confirm with apk info -v openssh-server that the version meets the table. Fixed packages exist even for branches that no longer get regular updates, but this is a good moment to move to a supported branch. On Alpine official cloud images on AWS or Azure, the default alpine user has passwordless doas, so a bypass can reach root. Rebuild from 3.21.10 / 3.22.8 / 3.23.8 / 3.24.4 or later images, or update running instances with the commands above.

Alpine says containers that do not run sshd are not affected. For images that bundle sshd, update the base image, rebuild and redeploy. In the Dockerfile, upgrade packages before installing sshd and bake in PasswordAuthentication no if your use case allows it.

Whether a tag such as alpine:3.24 already contains the fixed package depends on the registry, which we could not confirm. After building, always verify with apk info -v openssh-server. For third-party sshd images such as panubo/docker-sshd, the GitHub issue (#93) was still open when we checked, so we could not confirm a fix; check with the maintainer and set PasswordAuthentication no meanwhile.

These use musl and are listed as affected by the sshole site. We could not confirm a fixed OpenWrt package version from official sources, so check each project's security announcements and package feed. For vendor firmware, wait for the vendor notice. Until then, disable password logins and restrict SSH reachability as described below. A report says that a standard Yocto layout with locked "*" service accounts and an account with a $6$ hash was reproducible.

The upstream fix is in OpenSSH 10.6p2. Update to 10.6p2 or later, or apply GitHub commit 4353fdc. The researcher's repository carries the upstream fix as a patch for older versions, and its README says it applies to 7.3p1 and later. If you redistribute your own build, update the recipients too.

The workaround is to stop password logins. Alpine's advisory gives the following drop-in procedure (run as root). Keep an existing SSH session open and test key login from a second session so you do not lock yourself out.

If the last line prints passwordauthentication no, the setting is active. The sshole site also says this closes the entry point. Key-based login is unaffected, but register public keys first if you rely on passwords.

Supporting measures (none replaces the fix):

- Limit who can reach SSH: allow port 22 only from fixed IPs, a VPN or a bastion, via firewall or security groups
- Move to key-only authentication: confirm keys are registered before disabling passwords
- Tidy accounts: remove unused accounts and review locked service accounts. Alpine says accounts locked with "!" are not affected, but it does not give a procedure for changing "*" to "!". Be aware of side effects such as breaking key login (Alpine once locked root with "!" and broke key login)
- PermitEmptyPasswords: neither Alpine's advisory nor the OpenSSH release notes say whether PermitEmptyPasswords no blocks this path, so do not rely on it

The researcher is Özgün Kültekin of Wakefield, credited in the OpenSSH release notes.

Before or right after patching, check whether someone already logged in. Alpine advises searching /var/log/messages for sshd lines reading "Accepted password for" on accounts that have no password, and reviewing doas use, new users, files and authorized_keys.

On hosts that never use passwords, even one "Accepted password for" line suggests unauthorized access. Log locations vary (/var/log/auth.log, remote syslog). If found, isolate the host, rotate credentials and keys, and check for lateral movement.

- Inventory Alpine/OpenWrt/Buildroot/Yocto machines, VMs and containers that run sshd
- Run sshd -T on each and check passwordauthentication and usepam
- In /etc/shadow, find accounts with "*" and accounts with $5$/$6$ hashes
- Run apk upgrade -U -a then rc-service sshd restart on Alpine, and confirm the version
- For hosts you cannot update, set PasswordAuthentication no and restart sshd
- Restrict port 22 to a VPN, fixed IPs or a bastion
- Search /var/log/messages and similar logs for "Accepted password for"
- Rebuild and redeploy Alpine-based images that bundle sshd
- For OpenWrt and embedded devices, watch vendor notices and keep the mitigation until fixed
- To avoid missed updates, see our patch and update management guide

If you are rethinking your SFTP/SSH server design, our Google Cloud FTP/SFTP server guide may help with exposure and authentication choices.

- OpenSSH 10.6p2 release notes: https://www.openssh.org/releasenotes.html#10.6p2
- Alpine Linux advisory (2026-11-05): https://alpinelinux.org/posts/2026-11-05-openssh-password-authentication-bypass/
- GitHub commit 4353fdc: https://github.com/openssh/openssh-portable/commit/4353fdc43ef646c43a8dda7025cc1a898caf1482
- NVD CVE-2026-123158: https://nvd.nist.gov/vuln/detail/CVE-2026-123158
- CVE record: https://www.cve.org/CVERecord?id=CVE-2026-123158
- CISA KEV catalog: https://www.cisa.gov/known-exploited-vulnerabilities-catalog?field_cve=CVE-2026-123158
- Researcher site: https://sshhole.com/
- Researcher checker/PoC/patch (read before running): https://github.com/oz9un/sshole
- Help Net Security (Previdian, 2026-11-06): https://www.helpnetsecurity.com/2026/11/06/openssh-sshole-cve-2026-123158-exploitation/
- oss-security (Medcrypt, 2026-11-09): http://www.openwall.com/lists/oss-security/2026/11/09/27