# OpenSSH Auth Bypass on Alpine Linux via Long Passwords

> An OpenSSH vulnerability allows authentication bypass on Alpine Linux servers, enabling login to passwordless accounts using long passwords when PAM is not used.

- Published: 2026-11-05T21:42:22.000Z
- Severity: high
- Category: Vulnerabilities
- Tags: Authentication Bypass, Vulnerability, OpenSSH, Alpine Linux, Musl
- Author: Runtime Rebel Intel
- Primary source: https://thehackernews.com/2026/11/openssh-issues-emergency-fix-for-flaw.html
- Canonical: https://runtimerebel.com/blog/openssh-auth-bypass-on-alpine-linux-via-long-passwords

## Key points

- Immediate impact: Attackers can bypass authentication on vulnerable Alpine Linux servers to log into passwordless accounts.
- Affected systems: Alpine Linux servers running openssh-server without PAM, specifically those with a passworded account and an exposed passwordless account.
- Remediation: Update OpenSSH to 10.6p2 or patched Alpine Linux releases, or disable PasswordAuthentication immediately.

A significant [vulnerability](/glossary#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](https://thehackernews.com/2026/11/openssh-issues-emergency-fix-for-flaw.html).

## 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](/glossary#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](https://nvd.nist.gov/vuln/detail/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](/glossary#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](/glossary#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](/glossary#secure-shell-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](/blog/dell-csm-critical-flaws-unauthenticated-admin-on-kubernetes-nodes), [Critical Citrix NetScaler Zero-Days: CVE-2026-88772 & CVE-2026-88771](/blog/critical-citrix-netscaler-zero-days-cve-2026-88772-cve-2026-88771)

---

AI-generated analysis from the primary source above; not human-reviewed before publication — verify anything operational against the original (https://runtimerebel.com/editorial). Quote with attribution and a link to the canonical URL: https://runtimerebel.com/blog/openssh-auth-bypass-on-alpine-linux-via-long-passwords