CybersecurityNov 6, 2026 · AltTab Dad

Alpine OpenSSH password bypass: how to tell if your SSH was hit

Who’s affected

You are in scope if all of these are true:

• You run Alpine’s openssh-server (no PAM) or openssh-server-pam with UsePAM no.
• PasswordAuthentication is yes (OpenSSH default unless you changed it).
• The machine has an account with password field * (normal for key-only users, root:* since ~Alpine 3.16, the alpine user on tiny-cloud images, or directory-service users via musl-nscd).
• At least one local account has a $5$ or $6$ password hash (one passworded user is enough to unlock the * accounts).

Affected releases Alpine checked: 3.16 through 3.24 and edge.

Who’s not affected

• Containers that do not run sshd.
• Systems with PasswordAuthentication no (including many cloud-init images).
• openssh-server-pam with UsePAM yes.
• Locked accounts (! in the shadow password field).
• Machines with no $-style password hashes at all.
• Debian/Ubuntu/Fedora-style PAM setups are outside Alpine’s advisory scope for this bypass path.

How to check

1. Confirm you are on Alpine and running sshd (rc-service sshd status or ps | grep sshd).
2. Check auth settings: sshd -T | grep -i passwordauthentication and whether PAM is in use.
3. Look for shadow * accounts: getent shadow | awk -F: '$2=="*"{print $1}' (as root).
4. Review logs for impossible password logins: /var/log/messages lines like Accepted password for on accounts that have no password (alpine, root, or key-only users).
5. On exposed hosts, also review doas use and recently added users, files, and authorized_keys.

What to do

1. Update now: apk upgrade -U -a, then restart sshd (rc-service sshd restart). Package upgrade alone does not replace the running daemon. Fixed point releases include Alpine 3.21.10, 3.22.8, 3.23.8, 3.24.4 (and backports through 3.16).
2. If you cannot update yet: set PasswordAuthentication no (keep a working key session open; test a new login before you disconnect), then restart sshd.
3. If you cannot rule out a login: treat the machine as compromised — rotate keys, audit accounts, and rebuild from a known-good image when needed.
4. tiny-cloud images: older images become exploitable once any $6$ hash appears (for example after setting a console password). Update or disable password auth on every running instance.

FAQ

• Does this hit my Docker app container? Only if that container itself runs sshd under the conditions above. Most app containers do not.
• Is root automatically takeable? Default PermitRootLogin prohibit-password blocks password root logins; Alpine warns another password-reachable account that can doas to root is still enough.
• Is this the same as yesterday’s DreamHost story? No. DreamHost was a hosted File Manager credential exposure. This is an Alpine/OpenSSH authentication bypass on servers you run.