# Alpine Linux openssh-server authentication bypass: password-less login via oversized password

> **Key takeaway:** A logic flaw in musl's crypt() interaction with OpenSSH's salt-borrowing code allows remote unauthenticated attackers to log into password-less accounts by sending passwords between 257 and 1024 bytes.

**Published:** 2026-11-05T14:03:18.948328+00:00 
**Source:** Alpine Linux Releases & Security 
**Category:** distro-news 
**Canonical URL:** https://fosswire.org/news/alpine-linux-openssh-server-authentication-bypass-password-l.html 

## Summary
Alpine Linux has disclosed a critical authentication bypass in its openssh-server packages that allows remote attackers to log into accounts without knowing any password. The vulnerability affects all checked Alpine releases from 3.16 through 3.24 and edge, specifically when sshd is built without PAM (the default) or when openssh-server-pam runs with UsePAM no, PasswordAuthentication is enabled, at least one account has no password set (indicated by * in the password field), and at least one other local account uses a $5$ or $6$ password hash. The attack requires a single connection with a 257-1024 byte password and succeeds reliably without retries.

The root cause lies in how OpenSSH's non-PAM code path handles password verification: when an account lacks a proper hash to provide a salt, sshd borrows the salt from another account's hash. musl's crypt() function returns the string * as an error indicator when the input key exceeds 256 bytes. Since * is also the stored password field for accounts with no password, the comparison erroneously succeeds. Alpine has released fixed packages across all supported and even some end-of-life branches, and strongly advises administrators to either update and restart sshd, or immediately disable password authentication as an interim mitigation.

## Vulnerability mechanism and affected configurations
- **Salt-borrowing logic in non-PAM builds:** OpenSSH's password verification, when compiled without PAM, calls crypt() and compares the result to the stored hash; for accounts with no hash (password field *), it reuses another account's salt to perform the comparison.
- **musl crypt() behavior:** The musl C library's crypt() implementation returns the literal string * when the supplied key exceeds 256 bytes, which coincidentally matches the stored password field for accounts without passwords.
- **Attack prerequisites:** Successful exploitation requires PasswordAuthentication yes, at least one account with password field *, at least one account with $5$ or $6$ hash, and either openssh-server (default, no PAM) or openssh-server-pam with UsePAM no.
- **Default exposure in base images:** Alpine's base image sets root:* since approximately 3.16, and the tiny-cloud images ship an alpine user with * password field plus passwordless doas, creating a direct path to root compromise once any $6$ hash exists on the system.
- **Fix availability:** Patched packages are available for all branches from 3.16 through edge, with versions ranging from 9.0_p1-r6 (3.16) to 10.6_p2-r0 (edge); package upgrade alone does not restart sshd, requiring explicit service restart.

## Why it matters
This vulnerability is particularly severe for Alpine's core deployment scenarios—containers, edge devices, and cloud instances—where lightweight musl-based systems are prevalent and sshd may be the sole remote access path. The combination of default * password fields for system accounts and the common practice of adding password-hashed administrative accounts later means many production systems may be silently exploitable; cloud image users face immediate root compromise through the alpine user and doas escalation path. For Linux distribution security practices broadly, this case highlights how C library implementation details in alternative libc implementations can introduce subtle, high-impact authentication flaws that differ from glibc-based systems.