OpenSSH flaw let long passwords bypass SSH authentication on Alpine Linux

How the flaw works

A critical flaw in OpenSSH allowed attackers to log in to some Alpine Linux servers by entering a very long password, even if the account had no password set. According to The Hacker News↗ (opens in a new tab), the bug affected Alpine Linux systems running the standard openssh-server package, which is built without the Pluggable Authentication Module (PAM). Password logins are enabled by default on these systems.

The flaw is tied to how OpenSSH's server (sshd) interacts with musl, the C library Alpine uses. When an account has no password (marked with a '' in the password field), sshd borrows the salt (a random prefix used in password hashing) from another account with a real password. If an attacker submits a password longer than 256 bytes, musl's crypt() function returns '', which matches the stored '*', so sshd lets the login through. This bug only works if at least one other account on the system has a password hash starting with $5$ or $6$ (SHA-256 or SHA-512 hashes).

Who is affected

The flaw mainly affects Alpine Linux servers running the default openssh-server package with password authentication enabled and at least one account with a password. Accounts with no password set are at risk, including key-only users created without a password, users from directory services via musl-nscd, the root account (in Alpine base images since version 3.16), and the 'alpine' user in official cloud images. Other musl-based Linux systems, such as OpenWrt, Buildroot, and Yocto, may also be affected if they run OpenSSH without PAM, but OpenWrt uses Dropbear by default, which is not affected.

The response

OpenSSH released version 10.6p2 to fix the bug. Alpine Linux published updated packages for all supported releases and even for older, unsupported branches. Admins are urged to update their systems and restart the sshd service. If updating is not possible, disabling password authentication (setting PasswordAuthentication no) also blocks the attack. The OpenSSH team recommends treating any machine as compromised if you cannot rule out a login using this flaw.

What you should do

Admins should immediately update to the fixed OpenSSH version or Alpine package and restart sshd. If you cannot update right away, disable password logins and ensure SSH key authentication works before logging out. Check logs for suspicious logins to accounts with no password, and review recent user and file changes. If you find signs of compromise, treat the system as breached and investigate further.

Timeline

• August 9, 2012: musl change causes crypt() to return '*' on error.
• July 15, 2016: OpenSSH changes salt handling to address a previous flaw (CVE-2016-6210).
• Early November 2026: Flaw reported and fix developed.
• November 5, 2026: OpenSSH 10.6p2 and Alpine fixed packages released (The Hacker News↗ (opens in a new tab)).