THREATNOIR
Subscribe
Rapid alert3 min read

SSHole (CVE-2026-123158): OpenSSH authentication bypass hits Alpine and musl systems, exploited within hours

An OpenSSH flaw lets attackers log into passwordless accounts on Alpine Linux and other musl-based systems using an oversized password. One connection, no retries. Patched in 10.6p2 on 5 Nov, exploited in the wild within nine hours. What to do tonight.

Marcus Lenngren
Marcus Lenngren
Founder, ThreatNoir
Share this alert LinkedIn X Bluesky Reddit Email

OpenSSH 10.6p2 rapid alert: Your container built on Alpine? One SSH connection and root is theirs.
The rapid alert card: save it and share it with your team

What happened

OpenSSH shipped an emergency fix on 5 November for an authentication bypass nicknamed SSHole, tracked as CVE-2026-123158 (CVSS 8.1). On musl-based Linux systems, such as Alpine, with PAM disabled and password login on, an attacker can log into an account that has no password by sending a password between 257 and 1,024 characters.

The root cause goes back to 2016. To close a username enumeration flaw (CVE-2016-6210), sshd was changed to hash a password even when an account has no usable hash, borrowing another account's salt. Since 2012, musl's crypt() rejects SHA-256 and SHA-512 passwords longer than 256 bytes and returns "" on failure. Accounts configured for key-only or no login carry "" in /etc/shadow. The "" error value matches the stored "", and sshd lets the attacker in.

The flaw does not bypass passwords on accounts that have a real hash. OpenSSH developer Damien Miller says the bug is not in sshd itself but can be triggered through it. The 10.6p2 release blocks the path.

Timeline

  • 4 Nov: OpenSSH is told about the flaw.
  • 5 Nov: OpenSSH 10.6p2 ships; Alpine pushes patched packages for every branch from 3.16 to edge.
  • 5 Nov: Proof-of-concept exploits appear on GitHub (unverified, may contain malware).
  • Less than 9 hours after CVE publication: Previdian's sensors see the first attempt.
  • 6 Nov: Previdian confirms successful root access on an Alpine honeypot. Eight attempts seen so far, all from a single Japan-based address, 89.116.89[.]18, running id, uname and hostname.

CISA has not yet added it to KEV. Previdian has added it to its own known-exploited list.

Am I affected?

You are at risk if all of these hold:

  • OpenSSH runs on a musl-based system: Alpine, OpenWrt, Buildroot, Yocto, or many Docker images.
  • PAM is disabled (the default for Alpine's openssh-server package, or openssh-server-pam with UsePAM no).
  • SSH password authentication is enabled (the OpenSSH default).
  • At least one account has "*" in its password field (root since about Alpine 3.16, key-only users made with adduser and no password, the default alpine user in cloud images, or musl-nscd directory users).
  • At least one other local account has a $5$ or $6$ password hash.

Alpine's official AWS and Azure tiny-cloud images (3.18.11 through 3.24.3) ship a default alpine account with "*" and passwordless doas, so a login there is effectively root.

Not affected: glibc systems (Debian, Ubuntu, Fedora), PAM-enabled setups (UsePAM yes), Dropbear, OpenBSD, and containers that do not run sshd.

What to do now

  1. Update OpenSSH. On Alpine: apk upgrade openssh. Fixed releases include 3.21.10, 3.22.8, 3.23.8 and 3.24.4. A lower version number may still be patched.
  2. Restart sshd. Updating alone leaves the old daemon running and still vulnerable. Keep an existing session open while you do this.
  3. If you cannot patch yet, set PasswordAuthentication no in sshd_config, confirm key-based access works, and restart sshd.
  4. Block or watch the known source IP 89.116.89[.]18.

How to hunt

Look for password logins to accounts that should not accept one:

  • grep "Accepted password" /var/log/messages
  • If the alpine, root or a key-only user appears, check the shadow field: grep '^alpine:' /etc/shadow. A "*" there plus a successful password login is a strong sign of exploitation.
  • Review doas use, recently created users and authorized_keys files.

If you cannot rule out a login, treat the machine as compromised.

What does not help

  • Running apk upgrade without restarting sshd. The running daemon keeps accepting connections.
  • Relying on PermitRootLogin to protect you. The larger risk is indirect root through accounts like the default alpine user with passwordless doas.
  • Downloading the GitHub PoCs. Previdian warns they are unverified and may contain malware.

Sources

Pass this alert on LinkedIn X Bluesky Reddit Email

Drafted with the help of AI, then checked, edited and approved by Marcus Lenngren, who takes editorial responsibility for it.

More from us