Portable OpenSSH 10.6p2, released November 5, addresses a critical password-authentication bypass affecting some Linux systems that use musl libc with PAM disabled. The practical risk is not that every SSH password can be bypassed. It is that certain accounts administrators intended to keep inaccessible by password can accept a password login under a specific combination of server settings and account state.

For small businesses and government contractors running Alpine-based cloud hosts, appliances or custom Linux images, the immediate task is to identify the actual SSH server and authentication configuration—not assume that a key-only operating practice means password authentication is disabled on the server.

What the sources establish

OpenSSH's release notes describe 10.6p2 as a critical security workaround for musl Linux systems with PAM disabled. The project considers the root cause to be outside sshd, while confirming that the bypass is exploitable through sshd and can be avoided there.

Researcher Özgün Kültekin of Wakefield explains that musl's password-hashing error return can match the single asterisk stored in an account's password field. In the affected authentication path, a hashing failure can therefore be mistaken for a successful password comparison. The researcher traces the interaction to older changes, including a 2016 OpenSSH timing-defense change. November 5 is the current disclosure and fixed-release date, not evidence that attacks began today.

Check the conditions together

The researcher's affected-system checklist requires all of the following:

  • OpenSSH's server runs on a musl-based Linux system.
  • PAM authentication is not being used.
  • SSH password authentication remains enabled.
  • A target account has exactly a single asterisk as its stored password field.
  • Another account has a real password hash.

A valid password hash is not the same as the asterisk sentinel involved here. Likewise, a user who normally authenticates with a key is not necessarily protected if the server still offers password authentication and the account meets the vulnerable conditions.

Kültekin identifies Alpine Linux, OpenWrt, Buildroot and Yocto as environments to check, not as proof that every deployment is vulnerable. The researcher says the default alpine user in Alpine's official AWS and Azure images has passwordless doas privileges, making a successful login potentially a route to root when the other required conditions are present. That is a conditional impact statement, not evidence that every fresh cloud instance is exposed.

The researcher identifies glibc-based systems and PAM authentication paths as unaffected by this particular attack. An Alpine-based container without an SSH server is not an exposed SSH endpoint merely because its base image uses musl.

Actions for lean infrastructure teams

  1. Inventory the serving process. Identify hosts, management interfaces and custom images actually running OpenSSH sshd. Record the libc, PAM use, effective password-authentication policy and relevant account state. Review cloud images and appliance builds separately from mainstream workstation Linux.
  2. Close the unnecessary password path. Where keys are the intended access method, the researcher recommends PasswordAuthentication no. Validate the effective configuration, including applicable overrides, before restarting or reloading the service. Keep a tested recovery or console path so an emergency change does not lock out administrators.
  3. Deploy a documented fix. OpenSSH confirms the workaround in Portable 10.6p2. The researcher recommends apk upgrade openssh on Alpine. Verify that your distribution or image supplier's installed package actually includes the fix; a completed package command alone is not confirmation, and upstream version labels may differ from vendor backports. Replace vulnerable templates as well as running instances.
  4. Investigate successful password logins. Compare SSH authentication records with accounts that should not have accepted passwords. Preserve historical logs and account/configuration evidence before making destructive changes. An unexpected successful password login deserves investigation; current account state alone does not prove what its state was at login time.
  5. Respond to the authority gained. If unauthorized access is established, investigate commands, privilege escalation, persistence and reachable secrets. Recover affected credentials and trusted deployment paths from a clean administrative environment. Patching the bypass stops that entry path; it does not establish that an earlier session was harmless.

Evidence limits

The reviewed researcher report and OpenSSH release notice do not establish confirmed exploitation in the wild, a campaign actor, victim counts or country attribution. They also do not provide a complete distribution-by-distribution affected-version matrix. The older CVE-2016-6210 discussed in the technical history concerns username enumeration; it should not be presented as an identifier for this newly disclosed bypass.

Bulwark assessment

This is an urgent configuration-and-patching problem for the affected subset, not a reason to characterize all Linux SSH services as compromised. The durable lesson is to make an intended access boundary explicit: if an account is meant to be key-only, verify that the server really refuses password authentication for it. Pair that control with vendor-fixed software, off-host logs and review of the privilege behind the account.

Primary source: OpenSSH release notes, including Portable OpenSSH 10.6p2 dated November 5, 2026.

Primary source: Özgün Kültekin's original musl/OpenSSH authentication-bypass research and mitigation guidance.

Secondary context: BleepingComputer's November 5 report.