An alarming security issue has surfaced affecting Alpine Linux deployments running OpenSSH without PAM (Pluggable Authentication Modules). This vulnerability lets attackers bypass password authentication altogether on certain user accounts. Alpine Linux has already released updates in its latest OpenSSH versions to address the problem.
What’s the vulnerability?
When Alpine Linux is using OpenSSH without PAM, an attack vector emerges due to how OpenSSH interacts with musl libc’s crypt() function. If a user account has a password field set to just an asterisk (*), and another local account has a hash using $5$ or $6$ formats, then a password-based login can be bypassed. This only works under these specific conditions.
The bypass becomes possible when a password input exceeds 256 bytes. Under musl’s crypt implementation, inputs longer than that are rejected, returning * as an error. When OpenSSH compares this result with the stored password field (which is * for the target account), the comparison misleadingly passes—allowing a login despite what should have been a failed authentication. Alpine identified that passwords between 257 and 1024 bytes trigger this behavior.
Affected systems & risk factors
This flaw doesn’t impact systems using PAM (i.e., where OpenSSH is configured with UsePAM yes) or systems where SSH is disabled. It mostly touches Alpine Linux environments using the standard openssh-server package. Many Alpine Cloud images (versions 3.18.11 through 3.24.3) include an “alpine” account that has passwordless doas privileges; if a qualifying password hash is later added to another account, the alpine account may be hijacked to gain root access.
Fixes & mitigations
Alpine Linux released patched versions—3.21.10, 3.22.8, 3.23.8, and 3.24.4—to resolve the issue, and also ported fixes to older branches. Users are advised to run apk upgrade -U -a followed by restarting the SSH daemon to apply the updates. Since updates alone won’t activate the patch for a running process, a restart of sshd is essential.
Where immediate patching isn’t feasible, administrators should disable password authentication entirely (set PasswordAuthentication no), confirm SSH key-based login works before doing so, and keep an existing session alive during restarts. Reviewing logs for unexpected “Accepted password for” entries or odd doas behavior, and checking for unauthorized keys, is also recommended. In cases where compromise cannot be ruled out, systems should be treated as potentially breached.
This vulnerability follows earlier OpenSSH security updates, but is distinct in that it exploits flaws in password checking rather than encryption or protocol issues. So far, no CVE identifier had been attached at the time of Alpine’s advisory.
Why this matters: The flaw exposes non-passworded accounts (i.e. with * entries) to real risk whenever a qualifying password hash is added elsewhere, often during user management operations. Even strict separation of roles can fail if configuration slips occur.
This bug underscores the risks of relying solely on default configurations—especially in lightweight distros like Alpine that prioritize simplicity and minimalism. As containers and VMs increasingly use Alpine base images, a single misconfigured setting can cascade into full system compromise. What to watch: regularly audit account password fields; ensure you’ve applied the latest patches; and if using Alpine, double-check that password authentication is fully disabled where not needed.
Going forward, the community should push for similar input-length checks and validation fixes upstream, and verify that SSH implementations paired with musl (or any libc) behave correctly under edge-case inputs. Administrators and security teams must closely monitor for disclosed vulnerabilities that revolve around authentication quirks—these often are the most damaging.
