The OpenSSH project shipped OpenSSH Portable 10.6p2 on Nov. 5, 2026, a release its release notes describe as containing "a critical security workaround that affects Linux systems that use the musl libc and PAM disabled." This is not a bug that touches every Linux server. It hits a narrower group that is still common: machines whose SSH server runs on musl, the lightweight C library behind Alpine Linux, and that don't use PAM to handle logins.

On those systems, according to the National Vulnerability Database entry for CVE-2026-123158, "for some configurations of accounts, any password between 256 and 1024 characters succeeds." In other words, the password check can wave through a login it should reject. The record names Alpine Linux as an example of a platform using musl without PAM.

Here is what happened, who should worry, and what to do about it.

What exactly broke?

Two terms first. libc is the standard C library, the low-level code nearly every Linux program uses for basic jobs such as checking a password against its stored hash. Most big distributions, including Debian, Ubuntu and Red Hat, use GNU's glibc. Alpine and some embedded systems use musl instead, which is smaller. PAM (Pluggable Authentication Modules) is a separate layer many distributions put between sshd and the system's password database. When sshd is built without PAM, it checks passwords on its own, using the libc's password routines.

According to the release notes, sshd in 10.6p2 now avoids a "password authentication bypass that is exploitable through sshd(8) that affects some Linux systems when built and run with PAM support disabled." The OpenSSH team says it considers the root cause of the bug to be outside sshd, but that it is exploitable via sshd and can be avoided there. That is why the fix is called a workaround: sshd now guards against bad behavior in the layer beneath it rather than fixing its own mistake. The NVD description matches. It says OpenSSH versions before 10.6p2 on Linux, with musl and without PAM, lack a workaround for the bypass.

The issue was reported by Özgün Kültekin of Wakefield, the release notes say.

How serious is it?

The NVD record lists a CVSS 3.1 score of 8.1, rated High. The vector says it can be attacked over the network (AV:N), with high attack complexity (AC:H), which fits the fact that several conditions must all be true at once. The NVD record is still marked "Received," which means NVD's own analysis is pending. CISA's SSVC data in the record lists exploitation status as "poc." That means proof-of-concept material is public, though it doesn't confirm attacks in the wild. Defenders should assume the details are known.

Cyber Security News reports that a vulnerable setup needs all of the following:

  • The target account has * in its password field, which is the usual marker for an account with no usable password.
  • Another local account holds a password hash in the SHA-256-crypt ($5$) or SHA-512-crypt ($6$) format.
  • Password authentication is enabled in sshd.
  • The SSH port can be reached by the attacker.
  • The attacker knows the account name.

The worst part is the first condition. Accounts with no password are often treated as locked and therefore safe, with no further hardening. This bug undoes that assumption on affected systems. An account that was supposed to be impossible to log in to with a password can become reachable with one.

Who is not affected?

The scope is narrower than the headline suggests, and the sources agree on the edges:

  • glibc distributions. IONIX, a security vendor whose blog post calls the bug "SSHhole" (note that IONIX sells exposure-management products), says Debian, Ubuntu, RHEL and their derivatives are not affected.
  • PAM-enabled sshd on Alpine. Cyber Security News reports that Alpine's standard openssh-server package, which is built without PAM, is affected. The openssh-server-pam package with UsePAM yes is not.
  • Containers without a running SSH server. Many Docker images use Alpine as a base. Cyber Security News notes that such containers are unaffected, and that using an Alpine container image alone does not establish exposure.

That last point will spare a lot of teams. Alpine is everywhere in container images, but most of those containers never run an SSH daemon. Where exposure does exist, it tends to sit in less visible places: Alpine-based jump hosts, small VMs, appliances and embedded devices built on musl, and "debug" containers someone left with sshd turned on.

What else is in the release?

Besides the security fix, 10.6p2 includes bug fixes. It now allows ssh-mldsa44-ed25519 as a CA signature algorithm, and it fixes a CPU spin of under one second related to the ChannelTimeout option. The release notes also say the team is receiving a large number of AI-assisted security reports and will, for now, make more frequent releases to get bug fixes to users sooner. Administrators should expect smaller, more frequent OpenSSH updates and should keep their patch process ready for them.

What It Means for Defenders

Find your exposure. List every host and container that runs sshd on musl, with Alpine as the most likely case, and check whether PAM is in use. A system with Alpine's default openssh-server package and password authentication enabled is the case to worry about. Machines on glibc distributions such as Debian, Ubuntu and RHEL are not affected, according to IONIX. Neither is sshd running with PAM, according to Cyber Security News.

Patch. The upstream fix is in OpenSSH Portable 10.6p2. IONIX says patched Alpine packages are available on every supported Alpine branch. Cyber Security News adds that older Alpine branches kept their original version numbers, so a lower OpenSSH version number does not automatically mean a system is still vulnerable. The suggested Alpine fix is to upgrade all packages with the apk package manager and then restart sshd, so the running daemon picks up the new binary. For container images, rebuild from an updated base and redeploy. Updating a package inside a running container won't survive the next restart.

If you can't patch right away, turn off password logins. Setting PasswordAuthentication no in sshd's configuration and restarting the service removes the attack path, according to both Cyber Security News and IONIX. Confirm key-based access works first and keep an existing session open. A host with password authentication disabled is not exposed through this bug, and it's a good moment to move holdout hosts to keys permanently.

Check accounts with no password. The bug targets accounts whose password field is *. On affected systems, review which of those accounts can log in at all. Make sure service and system accounts have a non-interactive shell where that makes sense, and limit who can log in over SSH with options such as AllowUsers or AllowGroups. These steps don't replace the patch, but they shrink what an attacker can reach.

Limit who can reach SSH. Exploiting this requires access to the SSH port. Firewalling SSH to management networks or VPN ranges sharply cuts the risk for internet-facing machines while you patch.

Look back through your logs. Public reproduction material is reported to exist, so on any exposed host that ran password authentication, check sshd's logs for successful password logins to accounts that should never log in. Cyber Security News suggests reviewing /var/log/messages for "Accepted password for" entries involving passwordless accounts, then looking for unexpected privilege-escalation activity and new authorized keys. Alpine advises treating a machine as compromised when unauthorized access cannot be ruled out, per Cyber Security News.

For CMMC and federal contractors: this plausibly maps to flaw remediation and identification and authentication requirements. Write down which assets you checked, which were affected, when they were patched or mitigated, and the log review you did. That record is the kind of evidence an assessor is likely to ask for.

Sources