SSHole: OpenSSH Password Bypass on Alpine and musl Linux

What to do

1. On Alpine, run apk upgrade -U -a and then rc-service sshd restart; upgrading the package does not replace the running daemon.
2. If you cannot patch right now, set PasswordAuthentication no in a file under /etc/ssh/sshd_config.d/, validate with sshd -t, and restart sshd, keeping a key-based session open while you do it.
3. Find every musl-based host and container that runs sshd, including Alpine cloud instances, appliances built with Buildroot or Yocto, and OpenWrt devices where OpenSSH replaced Dropbear.
4. Rebuild Alpine-based images that ship sshd and redeploy cloud instances from fixed point releases (3.21.10, 3.22.8, 3.23.8, 3.24.4 or later).
5. If any host was reachable with password logins enabled, review its auth logs before you consider it clean, and treat it as compromised if you cannot rule out a login.

How to check if you are affected or compromised

• Check the version: apk version openssh (Alpine) or ssh -V, and compare with the fixed packages above.
• Check the running config: sshd -T | grep -Ei 'passwordauthentication|usepam'. You are exposed only if password authentication is yes and PAM is not used.
• List accounts with '*' and accounts with real hashes: awk -F: '$2=="*"{print $1}' /etc/shadow and awk -F: '$2 ~ /^\$[56]\$/{print $1}' /etc/shadow. Exposure needs both.
• Search for password logins to accounts that have no password: grep 'Accepted password for' /var/log/messages, then review doas usage, new users and authorized_keys files on any hit.

What happened#

On November 5, 2026, OpenSSH released portable OpenSSH 10.6p2 to block a password authentication bypass that is "exploitable through sshd(8)" on some Linux systems built and run without PAM. Alpine Linux published an advisory and fixed packages for every branch from 3.16 to edge on the same day. Researcher Özgün Kültekin of Wakefield, who reported it, calls the bug SSHole. It is tracked as CVE-2026-123158, CVSS 3.1 score 8.1 from the CNA.

The cause is two decisions that each made sense in isolation. Without PAM, sshd checks a password by running it through crypt() and comparing the result with the stored hash. Since a 2016 fix for username enumeration (CVE-2016-6210), sshd borrows another account's salt when an account has no usable hash, so that every login takes the same time. musl libc's crypt() returns the string * on failure, and its SHA-crypt code fails for keys longer than 256 bytes. * is also the conventional password field for accounts that should never accept a password. If you send an oversized password to such an account, the hash comes back as *, it matches the stored *, and the login succeeds. Alpine's advisory says it "takes one connection, works every time, and needs no retries."

Who is affected#

All of these must be true, according to Alpine:

• sshd runs on musl. Alpine's openssh-server package is built without PAM, and openssh-server-pam is affected only with UsePAM no.
• PasswordAuthentication is yes, which is the OpenSSH default.
• The attacker knows the name of an account whose password field is *. That includes key-only users, directory-service users and root on Alpine since about 3.16. Root is still protected by the default PermitRootLogin prohibit-password.
• At least one other local account has a $5$ or $6$ hash.

Alpine says the official tiny-cloud images from 3.18.11 to 3.24.3 ship an alpine user with a * password and passwordless doas. They are safe on first boot but become exploitable as soon as any account on the machine gets a real password, and the result is effectively root. Kültekin's write-up also names OpenWrt, Buildroot and Yocto. OpenWrt uses Dropbear by default, which is not affected, so it matters there only if you installed OpenSSH. glibc distributions (Debian, Ubuntu, Fedora and RHEL), PAM-based setups and OpenBSD are not affected.

Do you really need to act?#

Only if you match the list above, and then today. Most internet-facing SSH runs on glibc distributions and is not affected. Alpine containers that do not run sshd, which is the usual case, are not affected either. But for the hosts that do match, there is nothing to brute-force. The attacker needs only a reachable port and an account name, and Alpine's own example accounts (alpine and key-only service users) are predictable. As of November 6 no vendor reported exploitation in the wild. However, the details are public, the CVE record links reproduction labs, and CISA's SSVC entry marks exploitation as "poc." Researchers quoted by SecurityWeek expect brute-force tools to add the trick within days.

What to do now#

1. Patch and restart: apk upgrade -U -a && rc-service sshd restart. The fixed Alpine packages range from openssh 10.6_p2-r0 on edge to 9.0_p1-r6 on 3.16. If you build OpenSSH yourself, use 10.6p2.
2. If you cannot patch yet, turn off password logins. Keep an existing key-based session open, add PasswordAuthentication no in /etc/ssh/sshd_config.d/, run sshd -t, then restart sshd. OpenSSH developer Damien Miller told affected users to do this "IMMEDIATELY."
3. Check the effective config with sshd -T | grep -Ei 'passwordauthentication|usepam', not just the file. Drop-ins and match blocks can override it.
4. Look beyond servers. Check appliances and embedded devices built with Buildroot or Yocto, OpenWrt routers with OpenSSH, and any Alpine-based image that bundles sshd for CI, dev containers or Git hosting. Rebuild those images.
5. Redeploy cloud instances from fixed point releases (3.21.10, 3.22.8, 3.23.8, 3.24.4) or patch them in place.

How to tell if you were hit#

Search /var/log/messages (Alpine) for Accepted password for on accounts that have no password, such as alpine, root or key-only users. Compare them against awk -F: '$2=="*"{print $1}' /etc/shadow. Exploit attempts use passwords of 257 to 1,024 bytes, but sshd does not log password contents, so the successful login line is the signal. On any hit, review doas usage, new accounts, changed files and ~/.ssh/authorized_keys. Alpine's advice is to treat the machine as compromised if you cannot rule out a login.

Timeline#

• Aug 29, 2012 — musl adds SHA-512 crypt with a 256-byte key limit, after earlier changing crypt() to return * on failure.
• Jul 15, 2016 — OpenSSH adds salt borrowing to fix username enumeration (CVE-2016-6210).
• Nov 5, 2026 — OpenSSH 10.6p2 and Alpine fixed packages released, and CVE-2026-123158 published.
• Nov 6, 2026 — No exploitation in the wild reported as of this date.

Vulnerability records

• CVE-2026-123158 · sshd in OpenSSH before 10.6p2 on Linux, when musl libc is used without PAM, lacks a workaround for a password authentication bypass (related to…

Sources

Original sources first: vendor and project advisories, CVE and government records, the discoverers’ write-ups. Every claim above links to one of these. See how the Security Desk works.

Original and primary sources

1. OpenSSH — Release notes, OpenSSH 10.6p2 openssh.org
2. Alpine Linux — openssh-server password authentication bypass alpinelinux.org
3. CVE.org — CVE-2026-123158 cve.org
4. Özgün Kültekin — SSHole write-up sshhole.com

Coverage and analysis

1. BleepingComputer — OpenSSH flaw lets attackers log into password-disabled Linux accounts bleepingcomputer.com
2. SecurityWeek — OpenSSH Rushes Patches for 'SSHole' Authentication Bypass securityweek.com
3. The Hacker News — OpenSSH Issues Emergency Fix for Flaw Letting Long Passwords Bypass SSH Auth on Alpine Linux thehackernews.com