A password-authentication bypass in OpenSSH affects some Linux systems built with musl libc and run with PAM disabled. OpenSSH version 10.6p2 contains a workaround and was released on November 5, 2026. Alpine Linux published a detailed configuration and remediation guide the same day. CISA later listed the issue as CVE-2026-123158 in its Known Exploited Vulnerabilities catalog.

The release notes describe the root cause as outside sshd, while noting that the daemon can avoid the exploitable path. That distinction matters. A package update fixes the build, but a running daemon keeps the old code until it is restarted.

The account combination

Alpine's advisory lists three conditions for exploitation. The SSH server must be built without PAM or must be configured with UsePAM no; PasswordAuthentication must remain enabled; and the system must contain at least one account whose shadow password field is * plus at least one local account with a $5$ or $6$ password hash.

The advisory says an attacker can then send a very long password and authenticate as an account with no password set. The account's password being * normally prevents password login, but the vulnerable parsing path can misinterpret the hash state in the presence of another valid hash. Root may be protected by the default PermitRootLogin prohibit-password, but a key-only account with another route to privilege escalation can still be valuable.

Not every Alpine host is affected. Systems with PasswordAuthentication no are outside the documented path. Systems using Alpine's PAM package with UsePAM yes are listed as not affected. Locked accounts with ! in the shadow field are different from accounts with *, and containers that do not run sshd are not relevant to this daemon flaw.

Why a restart is required

Alpine's fixed packages include OpenSSH 10.6_p2-r0 on the edge branch and patched builds for releases from 3.16 through 3.24. The advisory says operators must restart sshd after upgrading. For OpenRC that is rc-service sshd restart. The same requirement applies to any service manager that keeps the old process alive.

The fix has an important deployment detail: replacing the package does not replace the running sshd process. A package inventory may show the fixed version while the listening daemon still carries the vulnerable code.

Verification should compare the installed package, the executable path used by the service and the process that owns the listening socket. On hosts with containers or chrooted builds, check each process separately. A host-level scan does not prove that a container image was rebuilt or restarted.

A safe rollback path

Operators who cannot update immediately can set PasswordAuthentication no and restart sshd. They should verify key-based access first and keep an existing session open until a new login succeeds. An SSH configuration mistake can lock out the only administrative path.

The Alpine advisory also discusses drop-in files and version-specific configuration behavior. Older releases may ignore a newer drop-in directory. In those environments, confirm that the effective configuration includes the change. sshd -T can show the running configuration where the local build supports it.

Four inventory questions help prioritize:

  1. 1.

    Which systems run Alpine or another musl build with PAM disabled?

  2. 2.

    Which of those systems allow password authentication?

  3. 3.

    Do they contain key-only accounts with * password fields and at least one $5$ or $6$ hash?

  4. 4.

    Has sshd been restarted since the fixed package was installed?

The incident also affects evidence review. CISA lists active exploitation, which means a host with the vulnerable combination may have successful logins that look like password authentication. Operators should inspect authentication logs for accounts that normally use keys, unusual source addresses, privileged commands and new persistence created after an SSH login.

The control that remains reliable is to know the actual daemon state. A package report is useful evidence, but the process and effective configuration decide which code is listening.

References