OpenSSH Password Bypass Makes Key-Only Accounts Reachable

CISA added CVE-2026-123158 to the Known Exploited Vulnerabilities catalog on November 9 after successful attacks were observed against vulnerable OpenSSH systems. The bypass affects a specific intersection: Linux with musl libc, sshd password checks running without PAM, password authentication enabled, a reachable account whose stored password field is an asterisk, and at least one local account carrying a SHA-256 or SHA-512 crypt hash. Under those conditions, a 257-to-1,024-byte password can be accepted for an account intended to reject passwords.

OpenSSH 10.6p2 contains the upstream workaround, while Alpine has backported it across supported and several older branches. Operators should install the vendor package, restart the running daemon, prove the effective configuration, find every key-only and directory-backed account in scope, and review successful password logins and post-authentication activity. Disabling password authentication and restarting sshd closes the path when an immediate package update is not possible. A package update without a daemon restart leaves the old process serving traffic.

OpenSSH released Portable OpenSSH 10.6p2 on November 5 and described a critical workaround for password-authentication bypass on Linux systems using musl libc with PAM disabled. Alpine published a same-day advisory with the exact account and configuration conditions, fixed package versions and restart instructions. On November 9, CISA placed CVE-2026-123158 in its Known Exploited Vulnerabilities catalog with a November 12 federal remediation deadline.

The KEV status is supported by direct observation rather than a prediction score. GreyNoise says it deployed vulnerable research systems and first observed successful exploitation on November 7. Its public activity record shows attackers running discovery commands, checking cloud metadata and privilege paths, reading SSH material, modifying authorized-key files and attempting to install a Python remote-control agent. Those observations establish that the bypass works against reachable systems and that attackers moved past login into host discovery and persistence attempts.

That evidence does not prove every internet scan or failed SSH login used this flaw, and GreyNoise's systems were instrumented gridpoints rather than identified production victims. It does change the response threshold. An exposed host that matched the vulnerable conditions before patching should not be marked safe solely because its package now reports a fixed build. Operators need to determine whether a password session reached an account that was supposed to accept keys only and what the session did afterward.

The affected surface is narrower than all OpenSSH servers and broader than internet-facing Alpine hosts. The vulnerable password verifier runs on Linux linked against musl libc when PAM is not handling the check. PasswordAuthentication must be enabled for the applicable connection context. The target account needs an asterisk in its password field, and the system needs another local account with a dollar-prefixed SHA-256 or SHA-512 crypt hash that OpenSSH can borrow for timing-safe work.

Alpine's standard openssh-server package is built without PAM. Its openssh-server-pam package is not exposed when UsePAM is enabled, but becomes exposed if UsePAM is disabled. Key-only users created without a password, accounts set to an asterisk and some directory-service users without a local shadow entry can satisfy the target-account condition. Alpine also notes that root commonly carries an asterisk, although OpenSSH's default PermitRootLogin prohibit-password blocks this password path unless an operator changed it to permit root password login.

Many common deployments fall outside the path. Systems using glibc and PAM, OpenBSD itself, Dropbear, Alpine containers that do not run sshd, systems with PasswordAuthentication disabled, accounts locked with an exclamation mark and cloud images whose initialization explicitly disabled password login are not affected by the described chain. Inventory should therefore record the running libc, sshd build, PAM path, effective per-user configuration and password-field state rather than treating the operating-system name as the only filter.

The flaw emerges from components assigning the same one-character value two different meanings. Unix account databases have long used an asterisk where no real password hash should match. Musl's crypt implementation returns an asterisk when hashing fails instead of returning a null pointer. Its SHA-256 and SHA-512 crypt paths reject passwords longer than 256 bytes as a resource-control measure, so an oversized candidate produces the failure marker.

OpenSSH also performs a timing defense for users without a usable stored hash. Rather than fail immediately and reveal account state through response time, it can select a valid salt from another local account and perform comparable password-hash work. On a vulnerable musl system, a 257-to-1,024-byte candidate makes that borrowed-hash calculation fail to the literal asterisk. The result is then compared with the target account's stored asterisk, so two values that both mean failure compare as equal.

The upstream patch adds a minimum stored-hash length to the acceptance condition and adjusts password-value handling. The security property is the important part: an error sentinel or account-state marker must never be eligible as proof of authentication. This is an interaction flaw across account conventions, libc behavior and OpenSSH's timing defense, which is why a configuration that looked intentionally key-only could become reachable through the password method.

For portable builds, OpenSSH 10.6p2 is the fixed upstream release. Distribution users should follow their vendor's package boundary rather than comparing the displayed upstream number alone. Alpine lists fixed openssh packages for edge and branches 3.16 through 3.24, including 10.3_p1-r2 on 3.24, 10.2_p1-r1 on 3.23 and 10.0_p1-r11 on 3.22. These backports can be safe even though the upstream component version is below 10.6p2.

Alpine explicitly warns that upgrading the package does not restart sshd. Restart the service after updating, preserve an existing administrative session until a new key login is tested, and confirm that the running process maps to the fixed files. In immutable or containerized environments, rebuild from a fixed base, replace the workload and prove that no older image, node pool, recovery image or appliance partition remains reachable.

If the update cannot be installed immediately, set PasswordAuthentication to no, validate the configuration and restart sshd. Check the effective value rather than only one configuration file because included files and Match blocks can change behavior by user, address or group. Disabling passwords is a strong containment step for this path, but it does not remove any persistence or credentials an earlier successful session created.

Begin with the accounts whose stored password field was an asterisk and that sshd allowed to log in. Review authentication journals, syslog or auth logs for successful password sessions to those names, especially after public disclosure and from unfamiliar addresses. Correlate each acceptance with sshd child processes, shells, doas or sudo activity, file writes, package commands, service changes and outbound connections. A normal failed-password count is not a useful negative finding because the bypass can succeed on the first attempt.

Inspect user and root authorized_keys files, local accounts, groups, cron jobs, init scripts, shell profiles, SSH configuration, listening services and recently changed executables. GreyNoise observed attackers querying cloud metadata endpoints, checking container markers, reading password and key material and writing persistence. Review instance-role use, cloud audit events and secrets present on the host. Treat those artifacts as observed examples, not an exhaustive indicator list or proof that every attacker followed the same sequence.

If an unauthorized session executed commands, isolate and preserve the system before broad cleanup. Rebuild from trusted media when host integrity cannot be proved, rotate SSH keys and every secret the account or its privilege path could access, revoke cloud sessions or instance credentials where possible, and review adjacent systems reached from the host. Deleting one added key does not establish that the remaining operating system, container layers or service credentials are trustworthy.

The immediate fix belongs in OpenSSH and vendor packages, but operators can reduce the consequence of another authentication interaction bug. Disable password authentication where it is not required, restrict SSH reachability to managed access paths, remove dormant accounts, use distinct low-privilege administration identities and prevent routine users from escalating without an additional control. A key-only label in an account database is not a complete policy if the daemon still exposes a password method.

Asset discovery also needs to include places where a full server inventory often stops: minimal cloud images, rescue environments, network appliances, embedded Linux builds, self-hosted runners and containers that unexpectedly start sshd. Record libc and authentication-provider details in software inventories. A binary name and upstream version do not capture whether PAM is active or whether a vendor backported the fix.

The published record is unusually clear about configuration, patching and observed exploitation, but it does not identify the total number of compromised production systems or a single campaign behind all activity. Keep those unknowns separate from the proven facts. The defensible response is to find the exact exposed intersection, close it, replace the running daemon and investigate every system that could have accepted the malformed password.