Alpine Linux OpenSSH: password login bypass in sshd without PAM (CVE-2026-123158)

What happened

Alpine Linux published a security advisory for its OpenSSH server on 2026-11-05. It describes a password authentication bypass. Someone who can reach the SSH port can log in to accounts that have no password set. They do not need to know any password, and one connection is enough. No CVE ID had been assigned when Alpine published the advisory. The issue is now tracked as CVE-2026-123158.

On 2026-11-09, CISA added CVE-2026-123158 to its catalogue of known exploited vulnerabilities. CISA gives no details about the attacks.

According to Alpine, the cause is how sshd checks passwords when it is built without PAM. It hashes the password attempt with the C library function crypt() and compares the result with the stored password field. For accounts without a password, sshd borrows the salt of another account. musl, the C library Alpine uses, returns the string * from crypt() as an error when the password is longer than 256 bytes. * is also what the stored field contains for every account without a password, so the comparison matches and the login succeeds. The OpenSSH developers changed sshd to avoid this case (commit 4353fdc, in OpenSSH 10.6p2). They describe the bypass as affecting "some configurations and runtime configurations".

Who is affected

This is not a general OpenSSH problem on Linux. The Alpine advisory says you are affected only if all of the following are true:

• You run sshd on Alpine Linux with the openssh-server package, which is built without PAM. Or you run openssh-server-pam with UsePAM no.
• PasswordAuthentication is yes. This is the OpenSSH default.
• The system has an account whose password field in /etc/shadow is *. This includes:
  • root, which ships as root:* since about Alpine 3.16. root can only be reached directly if PermitRootLogin yes is set. However, any other reachable account that can become root, for example through doas, is enough.
  • Key-only users created with adduser without a password, or with usermod -p '*'.
  • Directory users coming through musl-nscd (nslcd, winbind, sssd).
  • The alpine user in the official tiny-cloud images.
• At least one local account has a $5$ or $6$ password hash.

Alpine names these affected releases: 3.21 to 3.24, edge, and the older releases 3.16 to 3.20.

Tiny-cloud images: the official tiny-cloud images from 3.18.11 to 3.24.3 ship an alpine user with a * password field and passwordless doas. They become exploitable as soon as any $6$ hash exists on the machine. This happens, for example, when an admin sets a console password or when user-data adds a user with hashed_passwd. An attacker can then log in as alpine and become root.

Not affected:

• Debian, Ubuntu, RHEL and other glibc-based distributions where sshd uses PAM. The faulty crypt() behaviour comes from musl.
• Docker and other containers that do not run sshd.
• Systems with PasswordAuthentication no.
• Systems using openssh-server-pam with UsePAM yes.
• Locked accounts whose password field starts with !.
• Systems where no account has a $-style password hash.
• Cloud images configured through cloud-init, which sets PasswordAuthentication no.

What to do now

1. Update openssh on every Alpine system that runs sshd: apk upgrade -U -a. The fixed package is included in Alpine 3.21.10, 3.22.8, 3.23.8 and 3.24.4. The fixed openssh package versions are:

   • edge: 10.6_p2-r0
   • 3.24: 10.3_p1-r2
   • 3.23: 10.2_p1-r1
   • 3.22: 10.0_p1-r11
   • 3.21: 9.9_p2-r1
   • 3.20: 9.7_p1-r6
   • 3.19: 9.6_p1-r3
   • 3.18: 9.3_p2-r4
   • 3.17: 9.1_p1-r7
   • 3.16: 9.0_p1-r6

   3.21 reached its end of support on 2026-11-01. Alpine still published fixed packages for all releases back to 3.16.

2. Restart sshd: rc-service sshd restart. Upgrading the package does not restart the running daemon. Without a restart, the system is still vulnerable.

3. If you cannot update right away, disable password logins. First make sure your SSH key login works, and keep your current session open until a new login has succeeded. Then set PasswordAuthentication no, including inside any Match blocks. Check the configuration with sshd -t, restart with rc-service sshd restart, and confirm the setting with sshd -T | grep -i passwordauthentication. The Alpine advisory linked below gives ready-made commands for this. Updating or disabling password logins is enough to close the hole.

4. Update all running instances from tiny-cloud images built before 3.21.10, 3.22.8, 3.23.8 and 3.24.4, or disable password authentication on them. These images do not contain the fixed package.

5. If you build OpenSSH yourself on a musl-based system without PAM, upgrade to OpenSSH 10.6p2.

6. Check exposed systems for signs of a break-in, as described below.

How to check whether you are affected

• Check the distribution: cat /etc/alpine-release. If the file does not exist, the system is not Alpine and this advisory does not apply.
• Check the installed package: apk info -v | grep openssh. Compare the version with the list above.
• Check the active sshd settings: sshd -T | grep -i -E 'usepam|passwordauthentication'. You are not affected by this issue if passwordauthentication no is shown, or if you use openssh-server-pam and usepam yes is shown.
• Find accounts without a password: grep -E '^[^:]+:\*:' /etc/shadow.
• Find accounts with a $5$ or $6$ hash: grep -E '^[^:]+:\$[56]\$' /etc/shadow.

If both searches return results, password authentication is enabled and the package is not yet fixed, the system is vulnerable.

Signs of a break-in: search /var/log/messages for sshd lines with Accepted password for an account that has no password, such as alpine, root or any key-only user. Also review doas use, recently created users, recently changed files and authorized_keys files on exposed machines. Alpine's advice: if you cannot rule out such a login, treat the machine as compromised.

Sources

• https://nvd.nist.gov/vuln/detail/CVE-2026-123158
• https://www.cisa.gov/known-exploited-vulnerabilities-catalog