CVE-2026-123158: OpenSSH password authentication bypass on musl systems

What CVE-2026-123158 is

CVE-2026-123158 describes a password-authentication bypass affecting certain Linux systems running OpenSSH’s sshd with the musl C library and without Pluggable Authentication Modules (PAM). Under affected account and daemon configurations, a remote attacker who can reach SSH may authenticate using an unusually long password without knowing the account’s real password.

The issue was publicly disclosed on November 5, 2026. The OpenSSH project shipped the workaround in Portable OpenSSH 10.6p2. The upstream release notes describe the root cause as outside sshd, while noting that it is exploitable through sshd and can be avoided there. That distinction matters: the practical exposure depends on the operating system’s C library, PAM build/runtime choices, account state, and SSH configuration.

Why the configuration matters

The affected path occurs when OpenSSH is built and run on Linux with musl and PAM support disabled. The authentication handling can misinterpret input as a password hash. Canonical describes affected password strings as 256–1024 characters. Alpine’s advisory gives the more specific operational conditions for its package: the attacker needs an account whose password field is *, at least one local account with a $5$ or $6$ hash, and password authentication enabled. In that setup, a very long password (257–1024 bytes) may authenticate as the passwordless account.

Those details are from the distribution advisory and should not be generalized into a universal exploit recipe for every system. Other musl-based distributions or custom builds should follow their own vendor status and package guidance.

Who is and is not exposed

Prioritize hosts that run a network-reachable sshd compiled for musl without PAM and allow password authentication. Alpine identifies its non-PAM openssh-server package as affected; its PAM package is affected only when UsePAM no is configured. Alpine’s advisory also lists conditions that remove exposure, including PasswordAuthentication no, PAM enabled with UsePAM yes, locked accounts, or the absence of a local SHA-256/SHA-512 password hash.

Red Hat states that its products are not affected because its OpenSSH builds use glibc and PAM by default. That statement applies to Red Hat’s evaluated products; it should not be treated as a substitute for checking custom containers or third-party builds on those hosts.

Patch and mitigation steps

1. Inventory. Identify Linux hosts using musl, determine whether PAM is disabled for sshd, and check if password authentication is enabled. Include Alpine servers, cloud images, containers that actually run sshd, and custom builds.
2. Update through the OS vendor. For Alpine, install the fixed package for the release branch. The Alpine advisory lists fixed package versions for supported branches, including 3.21.10, 3.22.8, 3.23.8, and 3.24.4. Other vendors may backport the fix, so use their advisory rather than relying only on an upstream version string.
3. Restart and verify. Restart the SSH daemon after updating. A package upgrade does not necessarily replace an already running process. Keep an existing administrative session open and verify a fresh key-based login before closing it.
4. If patching is delayed, disable password login. Set PasswordAuthentication no and restart sshd, after first confirming that your SSH key access works. This is a mitigation, not a replacement for applying the vendor update.
5. Review access. Check authentication logs and account activity for unexpected SSH sessions, especially for passwordless or key-only accounts, and rotate credentials or keys if you find suspicious access.

At publication, Ubuntu listed its affected OpenSSH package status as “Needs evaluation” across the displayed Ubuntu releases. That is a vendor status snapshot, not confirmation that all Ubuntu builds are vulnerable. Check the live distribution advisory and package status before taking action.

Takeaway

This CVE is a reminder to assess the actual build and runtime configuration of remote-access services. The headline “OpenSSH authentication bypass” sounds broad, but the published conditions narrow the risk to specific musl/PAM and account configurations. Patch promptly, keep password authentication disabled where it is not needed, and verify vendor-specific status.