VULNpocalypse
HighVulnerabilityPatch available

OpenSSH password bypass on Alpine and musl without PAM: locked accounts accept long passwords

On Alpine and musl systems with sshd built without PAM, a locked account accepts any long password. Update openssh and restart sshd.

Published
Fixed in
OpenSSH 10.6p2 (Alpine edge openssh 10.6_p2-r0); Alpine 3.21.10, 3.22.8, 3.23.8, 3.24.4 and later, with fixed packages also back to 3.16; restart sshd after upgrading
Exploitation
No. Neither OpenSSH nor Alpine reports in the wild exploitation; no CVE was assigned as of 5 November 2026

What happened

On 5 November 2026, Alpine Linux published an advisory, with a fix from the OpenSSH project, for a password authentication bypass in sshd when it is built without PAM, which is how Alpine’s default openssh-server package is built (Alpine Linux).

The flaw is in how the non-PAM path checks a password. sshd hashes the attempt with the system crypt() and compares it to the account’s stored password field. For an account whose stored field is too short to hold a salt, sshd borrows the salt of another account. On musl, crypt() returns the single character * as an error marker when the key is longer than 256 bytes, and * is also exactly what the stored field contains for an account with no password. So a password of 257 to 1024 bytes hashes to *, matches the stored *, and the login succeeds (Alpine Linux).

To exploit it an attacker needs the name of an account whose password field is *, at least one other local account with a $5$ or $6$ hash, and password authentication enabled. It takes one connection and no retries. As Alpine puts it, one user with a real password is enough to make every passwordless account reachable. The flaw was reported by Ozgun Kultekin of Wakefield; OpenSSH shipped the fix in 10.6p2. Coverage calls it severe but niche, because of the specific build and account conditions it needs (heise, Cyber Security News).

Am I affected?

You are affected only if all of these hold (Alpine Linux):

  • You run Alpine’s openssh-server (built without PAM), or openssh-server-pam with UsePAM no. openssh-server-pam with UsePAM yes is not affected.
  • PasswordAuthentication is yes, which is the default unless you changed it.
  • An account exists whose password field is *. Examples: root (shipped as root:* since about Alpine 3.16; PermitRootLogin prohibit-password protects root directly, but not if another account can escalate, for example through doas), key-only users added without a password, directory users seen through musl-nscd, and the alpine user in official tiny-cloud images.
  • At least one local account has a $5$ or $6$ hash.

You are not affected if the container does not run sshd, if PasswordAuthentication is no, if you use openssh-server-pam with UsePAM yes, if the account is locked with ! rather than *, if no account has a $-style hash, or if the image was configured by cloud-init, which writes PasswordAuthentication no. Alpine confirmed the issue on releases 3.16 through 3.24 and edge.

Cloud images: the official tiny-cloud images (qcow2, VHD and AMI) from 3.18.11 through 3.24.3 ship an alpine user with a * password field and passwordless doas. They are safe on first boot, but become exploitable as soon as any $6$ hash exists on the machine, for example when an admin sets a console password or user-data adds a hashed password. An attacker then lands a shell as alpine and uses doas to become root. Images built from 3.21.10, 3.22.8, 3.23.8, 3.24.4 and later carry the fix (Alpine Linux).

What to do now

  1. Update openssh. Run apk upgrade -U -a. The fixed packages are Alpine 3.21.10, 3.22.8, 3.23.8, 3.24.4 and edge openssh 10.6_p2-r0; Alpine also published fixes back to 3.16.
  2. Restart sshd: rc-service sshd restart. Upgrading the package does not restart the running daemon, so the old sshd keeps running until you do.
  3. If you cannot update, disable password logins. Write PasswordAuthentication no into a drop-in (read by default from Alpine 3.19):
sh
   mkdir -p /etc/ssh/sshd_config.d
   echo 'PasswordAuthentication no' > /etc/ssh/sshd_config.d/00-no-passwords.conf
   sshd -t && rc-service sshd restart
   sshd -T | grep -i passwordauthentication

The last command should print passwordauthentication no. Keep a working key-based session open while you test, and confirm key login still works before you close it.

  1. Check for compromise. Grep /var/log/messages for Accepted password for on accounts that have no password (alpine, root, key-only users), and review doas use, new users, changed files and authorized_keys. If you cannot rule out an unauthorized login, treat the machine as compromised (Alpine Linux).

Sources