Security news

High

OpenSSH flaw lets attackers log in without a password on Alpine, exploited

  • openssh
  • alpine-linux
  • authentication-bypass
  • ssh
  • actively-exploited
  • cisa-kev
  • cve-2026-123158

CVE-2026-123158 lets an attacker log in over SSH without a password on Linux systems using musl without PAM, such as Alpine. CISA lists it as exploited. Update to OpenSSH 10.6p2 or Alpine's fixed openssh package and restart sshd.

On 5 November 2026, the OpenSSH project released OpenSSH 10.6p2 with a critical security workaround for CVE-2026-123158, a password authentication bypass in sshd on Linux systems that use the musl C library with PAM turned off. Alpine Linux, the best-known platform built that way, published its own advisory and fixed packages the same day. Alpine says an attacker who can reach the SSH port can log in to some accounts without knowing any password, in a single connection. On 9 November, CISA added the flaw to its Known Exploited Vulnerabilities catalogue, based on evidence of active exploitation.

The bugs

CVE-2026-123158, sshd accepts a bogus password on musl systems without PAM. NVD describes it as affecting sshd in OpenSSH before 10.6p2 on Linux when musl libc is used without PAM. The CVSS 3.1 base score listed in NVD is 8.1 (high), with no privileges or user interaction needed. OpenSSH says it considers the root cause to be outside sshd, in how the C library reports an error, but that it is exploitable through sshd and can be avoided there.

Alpine says a system is affected when all of these are true:

  • It runs the Alpine openssh-server package, which is 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 OpenSSH default.
  • At least one account has no password set, which is normal for key-only accounts and for root in Alpine base images.
  • At least one other local account has a standard SHA-256 or SHA-512 password hash.

The accounts without a password are the ones an attacker can get into. Alpine notes that root is still protected by the default PermitRootLogin prohibit-password, but that does not help if another reachable account can become root, for example through doas. Alpine also warns about its official tiny-cloud images from 3.18.11 to 3.24.3: they ship an alpine user with no password and passwordless doas, and become exploitable as soon as any password hash is added to the machine. Images configured through cloud-init, which turns password logins off, are not affected, and neither are containers that do not run sshd.

Mainstream distributions that use glibc and PAM, such as Debian, Ubuntu and Red Hat, are not in the affected group described by OpenSSH and NVD.

The remedy

A fix is available, and updating OpenSSH and then restarting sshd is the complete fix. Updating the package alone does not replace the daemon that is already running.

  • OpenSSH portable: 10.6p2 or later.
  • Alpine Linux: run apk upgrade -U -a, then rc-service sshd restart. Alpine 3.21.10, 3.22.8, 3.23.8 and 3.24.4 contain the fixed package. The fixed openssh package versions are 10.6_p2-r0 (edge), 10.3_p1-r2 (3.24), 10.2_p1-r1 (3.23), 10.0_p1-r11 (3.22) and 9.9_p2-r1 (3.21). Alpine has also published fixed packages for releases that no longer get regular updates: 9.7_p1-r6 (3.20), 9.6_p1-r3 (3.19), 9.3_p2-r4 (3.18), 9.1_p1-r7 (3.17) and 9.0_p1-r6 (3.16).

To confirm, check the installed package with apk info -v openssh and make sure it matches or is later than the version for your branch, then confirm that sshd was restarted after the upgrade. Cloud images built from earlier point releases do not include the fix, so update every running instance.

Because CISA lists the flaw as exploited, also check exposed machines for signs of a break-in. Alpine suggests looking in /var/log/messages for sshd lines that accept a password for an account that has no password, and reviewing doas use, recently created users, files and authorised SSH keys. If you cannot rule out a login, treat the machine as compromised.

If you cannot update today

No setting makes an unpatched sshd on an affected system fully safe to leave as it is, so plan the update now. Until then, Alpine's advisory gives one temporary measure that closes this hole:

  • Turn off password logins by setting PasswordAuthentication no in your sshd configuration, then restart sshd. Make sure SSH key login works first, and keep your current session open until you have tested a new login. Running sshd -T should then report passwordauthentication no.

Sources

Source