Alpine Linux SSH Flaw Lets Anyone In With a 257-Byte Password

How the Alpine Linux OpenSSH password bypass works

The flaw is a collision between two things that both mean "no password": musl's error return and the shadow file's placeholder.

When sshd is built without PAM, it checks a password by running the attempt through crypt() and comparing the result to the stored password field. For an account whose stored field is too short to hold a salt, sshd borrows the salt of another account on the machine.

musl's crypt() returns the string * when the key is longer than 256 bytes. * is also exactly what sits in the password field of every account with no password set. The "hash" matches, and the login succeeds.

The attacker needs two things: the name of an account whose password field is *, and at least one other account with a $5$ or $6$ password hash. Then a single connection with a 257-to-1024-byte password gets a shell. No retries, no guessing, no password.

• Affected: Alpine's openssh-server (no PAM) and openssh-server-pam with UsePAM no.
• Affected: every Alpine release checked, 3.21 through 3.24 and edge, plus unsupported 3.16 to 3.20.
• Not affected: containers that don't run sshd, openssh-server-pam with UsePAM yes, and systems with no $5$/$6$ hashes.

Who is actually exposed

Plenty of ordinary Alpine setups qualify, because key-only accounts are the norm on servers.

root ships as root:* in the base image from about Alpine 3.16, so it counts as a passwordless account. OpenSSH's default PermitRootLogin prohibit-password keeps root out — unless PermitRootLogin yes is set, or another login account can become root through doas.

Any key-only user created with adduser without a password, or with usermod -p '*', is a target. So are users coming from a directory service through musl-nscd, since they have no shadow entry.

The official tiny-cloud images from 3.18.11 through 3.24.3 are safe on first boot but become exploitable the moment any $6$ hash exists on the machine — an admin setting a console password, or user-data adding a user with hashed_passwd. The attacker then gets a shell as alpine and can use passwordless doas to become root.

How to fix it — and why upgrading alone isn't enough

Alpine has fixed packages, but the running daemon keeps the old code until you restart it.

Alpine 3.21.10, 3.22.8, 3.23.8 and 3.24.4 contain the fixed package. After upgrading, run rc-service sshd restart. Upgrading the package does not restart a running sshd, so the hole stays open until you do.

If you cannot update yet, disable password logins. Set PasswordAuthentication no in your sshd configuration and restart sshd. Either step closes the hole.

On releases older than 3.19, the drop-in directory isn't read, so the sed approach on /etc/ssh/sshd_config is the one that works. Test a new key login before closing your current session.

• Upgrade openssh, then rc-service sshd restart.
• Or set PasswordAuthentication no and restart sshd.
• Check /var/log/messages for 'Accepted password' lines for accounts that have no password.
• If you can't rule out a login, treat the machine as compromised.

What it means for you

If you run Alpine on a VPS, a home server or a cloud instance with sshd exposed, this is a patch-now situation. The fixed packages are in the Alpine repositories for 3.21.10, 3.22.8, 3.23.8 and 3.24.4, and back to 3.16 for older releases. No CVE had been assigned when the advisory went out, so vulnerability scanners may not flag it yet.

Docker and container users who don't run sshd inside the container are not affected. Cloud images configured through cloud-init, which writes PasswordAuthentication no, are also clear.

The fix is a package upgrade plus a restart, or one config line. The work is checking whether anyone already used the hole — and on a machine that has been exposed, that means reading logs before you assume you're clean.