OpenSSH Auth Bypass on Alpine Linux via Long Passwords

A significant vulnerability has been discovered in OpenSSH, specifically affecting installations on Alpine Linux. This flaw, enabling an authentication bypass, permits attackers to log into passwordless accounts by supplying unusually long passwords. While no in-the-wild exploitation has been reported, the ease of exploitation under specific conditions necessitates immediate attention from administrators. The OpenSSH project has released an emergency fix, OpenSSH 10.6p2, to address this issue, advising users to update or implement mitigating configurations without delay, according to The Hacker News.

Technical Analysis of the OpenSSH Authentication Bypass

The core of this vulnerability stems from an interaction between the OpenSSH server (sshd) and musl, the C standard library utilized by Alpine Linux. Typically, sshd relies on the Pluggable Authentication Module (PAM) for password verification. However, Alpine’s default openssh-server package is built without PAM support, meaning sshd handles password checks internally.

When sshd attempts to verify a password, it uses the crypt() function from the C library to hash the provided password and compare it against the stored hash in /etc/shadow. Accounts configured without a password have a special * entry in their /etc/shadow field. For accounts with $5$ or $6$ hash types, the musl implementation of crypt() has a design characteristic: it refuses passwords longer than 256 bytes, returning * to signal this error.

Under these specific circumstances, sshd’s internal logic, which historically addressed CVE-2016-6210 by borrowing a salt from another account, encounters a critical flaw. If an attacker provides a password between 257 and 1,024 bytes long, and the target account is passwordless (i.e., has * in /etc/shadow), musl’s crypt() function returns *. This * then incorrectly matches the * stored for the passwordless account, granting successful authentication. This design quirk, present since a musl change in 2012 and an OpenSSH change in 2016, means the vulnerability has been latent for years.

The exploit conditions are precise and require four elements to be true on the target server:

• The sshd instance is built without PAM.
• Password logins are enabled (PasswordAuthentication yes).
• At least one account on the machine has a password, providing a salt for sshd to borrow.
• The target account for compromise has no password set (e.g., has * in /etc/shadow).

Notably, this vulnerability is not exclusive to Alpine Linux but affects any musl-based system running OpenSSH in this configuration. Özgün Kültekin, who reported the flaw, also names OpenWrt, Buildroot, and Yocto as potentially vulnerable if they run OpenSSH (OpenWrt uses Dropbear by default, which is not affected).

Special attention is required for Alpine’s tiny-cloud images from versions 3.18.11 through 3.24.3. These images include a passwordless alpine user with doas privileges. While initially safe, they become vulnerable once any $6$ hash exists on the machine (e.g., after an administrator sets a console password). This allows an attacker to log in as alpine and escalate privileges to root via doas.

OpenSSH 10.6p2 Patch Guidance and Mitigation

To address this critical flaw, OpenSSH has released version 10.6p2. This update introduces a change where sshd explicitly refuses a password match if the stored password field is shorter than four characters, effectively blocking the * match.

For Alpine Linux users, the most direct remediation is to update to the latest point releases: 3.21.10, 3.22.8, 3.23.8, and 3.24.4, or later versions, which include the fixed openssh-server package. Even unsupported branches 3.16 to 3.21 have received fixed packages. After updating, administrators must restart the sshd service, as package upgrades do not automatically do so.

If immediate patching is not feasible, administrators should disable password authentication as an interim measure. This can be achieved by:

• Ensuring SSH key-based login is functional and maintaining an active session.
• Setting PasswordAuthentication no in the sshd configuration. For Alpine systems from 3.19 onward, adding this setting via a drop-in file in /etc/ssh/sshd_config.d is recommended. Otherwise, modify /etc/ssh/sshd_config directly, checking for and updating lines within Match blocks.
• Verify the configuration with sshd -t and then restart sshd.
• A sshd -T | grep -i passwordauthentication command should confirm passwordauthentication no.

Detecting OpenSSH Long Password Authentication Bypass

Organizations should actively search for indicators of compromise (IoCs). Review sshd logs, typically found in /var/log/messages, for Accepted password for entries corresponding to accounts that are known to be passwordless, such as alpine, root (if PermitRootLogin yes is set), or other key-only users.

Furthermore, on potentially exposed machines, administrators should:

• Review recent doas usage, especially concerning privileged commands.
• Examine recently created user accounts.
• Audit newly created or modified files.
• Inspect authorized_keys files for unauthorized additions.

Any inability to rule out a suspicious login must lead to treating the affected machine as compromised and initiating incident response procedures. This proactive approach to mitigating musl crypt() vulnerability interactions is essential for maintaining server integrity.

Related: Dell CSM Critical Flaws: Unauthenticated Admin on Kubernetes Nodes, Critical Citrix NetScaler Zero-Days: CVE-2026-88772 & CVE-2026-88771