OpenSSH SSHole (CVE-2026-123158): Password Bypass on Accounts With No Password

Threat actors began attempting exploitation of the SSHole flaw — CVE-2026-123158 (CVSS 8.1) — within nine hours of disclosure, confirming root access on an Alpine Linux honeypot. A Nov 8 update counted 20 attempts from 13 IP addresses across nine countries.

The flaw lets an unauthenticated attacker supply an oversized password to access accounts configured with no usable password — no credential theft, no SSH keys needed. It affects Linux systems running OpenSSH on the musl C library with PAM disabled, including Alpine's default server configuration. glibc distributions, Dropbear, non-Linux systems, and PAM-based password checks are unaffected.

How It Works

The bug dates to a 2016 patch for CVE-2016-6210 (username enumeration). Under specific conditions, OpenSSH's password handling mistakes a failed hashing operation for successful authentication by producing the same * value that marks an account as password-disabled in the password field.

The attacker triggers it with an arbitrary password of 257–1,024 bytes. The hash attempt fails and returns *; the sshd daemon compares it against the * stored in the account's password field and lets the attacker in. Exploitation requires at least one account whose password hash is exactly *. Accounts with valid password hashes cannot be bypassed.

As Safe Security summarized: a successful attack grants access with the compromised account's existing permissions — and from there, deployment credentials, application secrets, and lateral movement.

Previdian's telemetry captured the honeypot root and reconnaissance commands (id, uname, hostname) from 89.116.89[.]18. The researcher behind the flaw, Ozgun Kultekin, announced it at sshhole.com; OX Security's breakdown is the deep technical write-up.

What to Do

• Install OpenSSH 10.6p2 (or your distribution's patched package) and restart sshd.
• Alpine's advice: search /var/log/messages for sshd lines reading Accepted password for an account that should not accept password logins (alpine, root, or any key-only user).
• Review doas use and recently created users, files, and authorized keys on exposed machines. If you cannot rule out a login, treat the machine as compromised.

Hardening So the Next One Fails

SSHole needs three preconditions at once: musl libc, PAM disabled, and an account whose password field is literally *. Remove any one and the chain breaks. Concretely: enable PAM on Alpine images and audit sshd_config for UsePAM yes; add the check awk -F: '$2 == "*"' /etc/shadow to your image build and workstation hardening so a passwordless-account landmine ships nowhere; and set PasswordAuthentication no wherever key-based access is already the norm — it removes the entire code path the flaw lives on. The patch matters most, but the hardening is what makes the next 2016-class bug a non-event.

And the operational lesson: disclose is not finish. Alpine's post gave the log-hunt line, but a fleet that only patches the package and never greps Accepted password for against its passwordless-account inventory will miss the backdoor-shaped question of whether a login already happened. Patch, then hunt, in that order — and treat any ambiguous result as a compromised machine.

Sources

• The Hacker News coverage
• NVD entry for CVE-2026-123158
• OX Security technical breakdown
• SSHole disclosure site
• OpenSSH 10.6p2 release notes