OpenSSH "SSHole" (CVE-2026-123158): Any Long Password Logs In on Alpine Without PAM

On November 5, 2026, the OpenSSH project shipped OpenSSH 10.6p2 as an emergency release to close a password authentication bypass on Linux systems that use the musl C library with PAM disabled. Alpine Linux, the best-known such system, published an advisory the same day. The bug, CVE-2026-123158, is nicknamed SSHole (the researcher styles it *sshole) and lets an attacker who can reach port 22 log in to accounts that were never supposed to accept a password at all.

It is no longer theoretical. GreyNoise saw its first successful exploitation of a vulnerable sensor on November 7, and CISA added the CVE to its Known Exploited Vulnerabilities catalog on November 9 with a November 12 deadline for federal agencies.

What happened

Linux marks an account that must never log in with a password by putting "*" in its password field in /etc/shadow. Key-only users, and root on Alpine since 3.16, look like this. No password hash can ever equal "*", so password logins should always fail.

Without PAM, sshd checks a password by hashing it with crypt() and comparing the result with the stored field. For accounts with no real hash, sshd borrows another account's salt so failed logins take the same time (a 2016 fix against username enumeration). The researcher's write-up traces the rest: musl's crypt() caps keys at 256 bytes and, on failure, returns the string "*". Send a password longer than 256 bytes and the "hash" comes back as "*", which matches the stored "*", and sshd lets you in.

The Alpine advisory sums it up: "It takes one connection, works every time, and needs no retries." OpenSSH says the root cause is outside sshd but fixed it there. NVD lists a CVSS 3.1 score of 8.1 from the CNA.

Who is affected

All of these must be true on the same machine:

• sshd runs on musl libc without PAM: Alpine's default openssh-server package, or openssh-server-pam with UsePAM no. Researchers also name OpenWrt, Buildroot and Yocto builds that ship OpenSSH this way.
• PasswordAuthentication is yes, which is the OpenSSH default.
• At least one account has "*" as its password field: root (reachable only with PermitRootLogin yes), a key-only user created without a password, users from a directory service through musl-nscd, or the alpine user in official tiny-cloud images.
• At least one other local account has a $5$ or $6$ hash, so there is a salt to borrow.

The cloud image case is the dangerous one. Alpine says its tiny-cloud images from 3.18.11 through 3.24.3 ship an alpine user with "*" and passwordless doas. They are safe on first boot, but as soon as anyone sets a console password or user-data adds a hashed password, an attacker can log in as alpine and become root.

Not affected: Debian, Ubuntu, RHEL, Fedora and other glibc distributions; systems with PasswordAuthentication no (cloud-init writes this); locked accounts with "!"; and containers built on Alpine that never run sshd.

How to check an Alpine host

# Distro, package and effective sshd settings
cat /etc/alpine-release
apk list -I 'openssh*'
sshd -T | grep -Ei '^(passwordauthentication|usepam|permitrootlogin) '

# Accounts with "*" (exposed) and accounts with $5$/$6$ hashes (the trigger)
awk -F: '$2=="*"{print "star:", $1}' /etc/shadow
awk -F: '$2 ~ /^\$[56]\$/{print "hash:", $1}' /etc/shadow

The host is exploitable until patched if passwordauthentication is yes, PAM is not in use (apk lists openssh-server rather than openssh-server-pam, or usepam shows no), and both awk commands print at least one account. Run the same checks inside any image that starts sshd, such as SFTP, bastion or dev containers.

What to do now

1. Upgrade and restart sshd

apk upgrade -U -a
rc-service sshd restart

Upgrading alone is not enough: the running daemon keeps the vulnerable code until it restarts. The fixed packages per branch, from the Alpine advisory:

2. If you cannot patch today, turn off password logins

Confirm your key login works and keep your current session open, then:

echo 'PasswordAuthentication no' > /etc/ssh/sshd_config.d/00-no-passwords.conf
sshd -t && rc-service sshd restart
sshd -T | grep -i passwordauthentication   # expect: passwordauthentication no

The drop-in directory is read by default from Alpine 3.19. On older releases set the same line in /etc/ssh/sshd_config itself, including inside any Match blocks.

3. Look for signs it already happened

grep 'Accepted password for' /var/log/messages

A successful password login for an account with "*" in /etc/shadow (alpine, root, a deploy user) means the host was exploited. Review doas use, new users, authorized_keys and recent files, and if you cannot rule out a login, rebuild the machine. Hardening sshd and auditing accounts like this is covered in our Linux Security Admin course. To check other CVEs on your exposure list, use the CVE lookup tool.

Frequently Asked Questions

Are Ubuntu, Debian or RHEL servers affected by SSHole?

No. The bug needs musl libc and sshd running without PAM. glibc distributions such as Debian, Ubuntu, Fedora and RHEL are not affected, and neither is Alpine's openssh-server-pam package with UsePAM yes.

Are Alpine-based Docker containers vulnerable?

Only if the container actually runs sshd with password authentication enabled. Most Alpine application images never start sshd and are not affected. Images built to offer SSH or SFTP access should be checked and rebuilt with the fixed package.

Which version fixes CVE-2026-123158?

Upstream fixed it in OpenSSH 10.6p2, released on November 5, 2026. Alpine backported the fix to every branch from 3.16 to edge, for example openssh 10.3_p1-r2 on Alpine 3.24 and 9.9_p2-r1 on 3.21. Restart sshd after upgrading, because the running daemon keeps the old code.

Is SSHole being exploited?

Yes. GreyNoise reported its first observed successful exploitation on November 7, 2026, and CISA added CVE-2026-123158 to its Known Exploited Vulnerabilities catalog on November 9 with a November 12 deadline for US federal agencies.

Sources

• Alpine Linux security advisory: openssh-server password authentication bypass
• OpenSSH 10.6p2 release notes
• NVD: CVE-2026-123158
• CISA Known Exploited Vulnerabilities catalog: CVE-2026-123158
• GreyNoise: SSHole (CVE-2026-123158) activity
• Researcher write-up (Özgün Kültekin, Wakefield)