OpenSSH 10.6p2 Fixes a Password Authentication Bypass on musl Builds Without PAM (CVE-2026-123158)

TL;DR - CVE-2026-123158 (“sshhole”) lets sshd in OpenSSH before 10.6p2 accept a password it should reject, but only on Linux builds that use musl libc without PAM, such as Alpine Linux, OpenWrt, Buildroot and Yocto. - Severity: 8.1 (High), CVSS 3.1 AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H. This is the CNA score from the CVE record; NVD analysis is pending. - It applies to a specific account configuration, described below, and not to a default install. - Not affected: glibc-based distributions, OpenSSH builds that use PAM, and Dropbear. - Fix: upgrade to OpenSSH 10.6p2 (on Alpine, apk upgrade openssh), or set PasswordAuthentication no. It was not in the CISA KEV catalog as of the November 4 catalog release.

What happened#

The CVE record for CVE-2026-123158 was published on November 5, 2026, with MITRE as the CNA. The record says sshd in OpenSSH before 10.6p2 on Linux, “when musl libc is used without PAM, lacks a workaround for a password authentication bypass (related to misinterpretation of whether a string is intended to be a password hash)”, and that “for some configurations of accounts, any password between 256 and 1024 characters succeeds.” The example platform it names is Alpine Linux. The weakness is listed as CWE-394 (Unexpected Status Code or Return Value).

OpenSSH addressed it in 10.6p2. The upstream commit (“avoid password authn bypass”) states: “We do not consider the root cause to be within OpenSSH but we are well equipped to avoid it.” The fix makes sshd treat a stored password field shorter than four characters, such as *, as never matchable, so a supplied password can no longer be accepted against it. The CVE record and the commit both point at how musl’s crypt() reports that case rather than at OpenSSH’s own logic.

The issue was published as “sshhole” at sshhole.com, which credits the researcher Ozgun Kultekin (Wakefield). We have not seen a report of exploitation in the wild, and the CVE was not in the CISA Known Exploited Vulnerabilities catalog as of its November 4 release.

Who is affected#

The conditions all have to hold at once:

• The OpenSSH build uses musl libc and is compiled without PAM. This is common on Alpine Linux and on embedded or container-oriented Linux built with OpenWrt, Buildroot or Yocto. The CVE record names Alpine as its example.
• OpenSSH is older than 10.6p2.
• PasswordAuthentication is enabled in sshd_config.
• The target account’s password field in /etc/shadow is * (a conventional “no password set / login disabled via password” marker), and at least one other account on the host has a real password hash. The combination is what makes sshd mishandle the * field as if it were a hash to compare against.

Under those conditions, a password between 256 and 1024 characters (1,024 being OpenSSH’s maximum accepted password length) is accepted for the * account. Shorter passwords are not.

Explicitly not affected#

• glibc-based distributions (most mainstream server Linux: Debian, Ubuntu, RHEL, Fedora, SUSE and their derivatives). The flaw is specific to musl’s behavior.
• OpenSSH builds that use PAM. The description scopes the bug to “without PAM”; a PAM-mediated password stack is not affected.
• Dropbear, a separate SSH implementation, is not OpenSSH and is not in scope here.

What defenders should do now#

1. Upgrade OpenSSH to 10.6p2 or later. On Alpine, apk update && apk upgrade openssh, then restart sshd. On OpenWrt, Buildroot or Yocto images, rebuild against the patched OpenSSH and redeploy. This is the real fix.
2. If you cannot upgrade immediately, disable password authentication. Set PasswordAuthentication no in /etc/ssh/sshd_config and reload sshd. Key-based authentication is unaffected by this issue, so a key-only configuration closes it regardless of libc or OpenSSH version.
3. Confirm what you actually run. Check ssh -V for the OpenSSH version and whether the build is musl-based and PAM-less (Alpine’s default openssh-server is). A glibc host or a PAM-enabled build does not need emergency action for this CVE, but patching when the update reaches your channel is still good hygiene.
4. Review accounts with a * shadow field on in-scope hosts that still allow password auth, since those are the accounts the bug can turn into a login path.

Detection#

On an affected host, a successful exploit shows up as an “Accepted password” log entry for an account whose /etc/shadow password field is * — that is, a password login for an account that was never supposed to accept a password at all. Review sshd authentication logs (for example /var/log/auth.log, /var/log/messages, or the systemd journal for the ssh service) for Accepted password for <user> lines, then cross-check whether each such <user> has a * password field in /etc/shadow. A match there, especially for a service or system account, is a strong signal and worth investigating.

Sources

• CVE-2026-123158 at NVD (analysis pending; the 8.1 score here is the CNA’s)
• CVE-2026-123158 record (CVEProject/cvelistV5)
• OpenSSH 10.6p2 release notes
• OpenSSH commit “avoid password authn bypass”
• Alpine Linux: OpenSSH password authentication bypass
• sshhole.com (researcher: Ozgun Kultekin, Wakefield)