OpenSSH released 10.6p2 on November 5 to fix a password authentication bypass, CVE-2026-123158 (its finder calls it sshole; CVSS 8.1). On November 9 the US Cybersecurity and Infrastructure Security Agency (CISA) added it to the Known Exploited Vulnerabilities (KEV) catalog, citing evidence of active exploitation. It only affects Linux systems that use the musl C library without PAM, and Alpine is the typical case. Ubuntu's security page marks openssh as "Not affected" on every release and Debian rates the urgency as unimportant, so a VPS running Ubuntu or Debian needs no action for this bug. What needs checking is Alpine systems, and any sshd you installed yourself inside an Alpine container. For the previous round of OpenSSH changes, see our October report.

All four conditions must hold

  • You run Alpine's openssh-server package, which is built without PAM, or you run openssh-server-pam with UsePAM no.
  • PasswordAuthentication is yes. That is the OpenSSH default, so it is on unless you changed it.
  • The machine has an account whose password field is *, meaning an account with no password that is meant to log in with keys only. Alpine's base image has shipped root as root:* since about 3.16, and the alpine user in the official tiny-cloud images is the same and has passwordless doas to root. Root itself is protected by the default PermitRootLogin prohibit-password, but that is not enough if another account can become root.
  • At least one other account on the machine has a real password hash starting with $5$ or $6$. When all four hold, an attacker who knows an account name sends a very long password of 257 to 1024 bytes (NVD words it as 256 to 1024 characters) and is logged in on the first connection. The cause is that musl's crypt() returns * as an error marker when the password is longer than 256 bytes, and * is exactly what those accounts store, so sshd sees a match.

What is not affected

  • Containers that do not run sshd, which covers the great majority of Docker containers.
  • Systems that already set PasswordAuthentication no; cloud images configured through cloud-init write that line. Systems using openssh-server-pam with UsePAM yes are not affected either.
  • The finder also names OpenWrt, Buildroot and Yocto as musl-based systems. They only matter if OpenSSH's sshd is installed, and the fix comes from each project's own updates.

How to fix it

  • Upgrade, then restart sshd: run apk upgrade -U -a, then rc-service sshd restart. Upgrading the package does not restart a running sshd. Alpine 3.21.10, 3.22.8, 3.23.8 and 3.24.4 contain the fixed package; the package versions are 10.3_p1-r2 on 3.24, 10.2_p1-r1 on 3.23, 10.0_p1-r11 on 3.22, 9.9_p2-r1 on 3.21 and 10.6_p2-r0 on edge, with fixes published for older branches back to 3.16.
  • If you cannot upgrade yet, turn off password logins: set PasswordAuthentication no in the sshd configuration, restart sshd, and confirm with sshd -T | grep -i passwordauthentication that it prints no. Make sure your key login works first, and keep your current session open.
  • If you wrote a Dockerfile that installs openssh-server into an Alpine image, pull the new base image, rebuild and restart the container. Upgrading the host does nothing for it.

How to tell whether someone logged in

Alpine says to look in /var/log/messages for sshd lines reading Accepted password for: a successful password login for an account that has no password (alpine, root, or a key-only user) means the bug was used. Then review doas use, newly created users and authorized_keys, and if you cannot rule out a login, treat the machine as compromised and follow our intrusion check and hardening guide. BleepingComputer reported on November 9 that GreyNoise recorded the first successful exploitation at 00:46 UTC on November 7, about 40 hours after the fix was released; after getting in, attackers ran system and container reconnaissance, queried cloud metadata services, tried to read password hashes and root's SSH keys, and edited authorized_keys to keep access. For container basics, see our Docker primer; on any distribution, key-only SSH login is the setting that saves the most trouble, as covered in ufw firewall and SSH key login.