sshole: a too-long password opens the door

At a glance

• CVE-2026-123158 — password authentication bypass in sshd. CVSS 3.1 score: 8.1 / 10 (high).
• Discovered by Özgün Kültekin, disclosed on November 5, 2026.
• Affected: OpenSSH built against the musl C library and without PAM — the default openssh-server package on Alpine, plus OpenWrt, Buildroot, Yocto.
• Not affected: glibc systems (Debian, Ubuntu, Fedora…) and any system authenticating through PAM.
• Fix shipped within 24 h: OpenSSH 10.6p2 and updated Alpine packages, on November 5, 2026.

The root cause: two good ideas that cancel out

The bug comes from combining two behaviours that are perfectly reasonable on their own.

On the musl side. Since 2012, musl's crypt() no longer returns NULL on failure, but the string * (a single asterisk).

On the OpenSSH side. Since 2016, to fix CVE-2016-6210 (user enumeration via response timing), sshd always computes a hash, even for an account with no usable hash — reusing the salt of another account to do so.

Now put them together: if an attacker sends a very long password (roughly 257 to 1,024 characters per the researcher), crypt() fails and returns *. But in /etc/shadow, an account with no usable password (root, a key-only user, a directory account) carries exactly the hash *. The two values match: sshd concludes the password is correct and accepts the connection.

Put plainly: the code meant to hide whether an account exists ends up validating authentication for that very account.

Exposure conditions (all required)

1. sshd runs without PAM (Alpine default, or openssh-server-pam with UsePAM no).
2. Password authentication is enabled (the default).
3. A target account has the hash * in shadow (key-only user, passwordless account…). Accounts locked with ! are not affected.
4. At least one other local account has a real SHA-256/512 hash: that's what provides the salt.

On official Alpine cloud images (AWS, Azure), from 3.18.11 to 3.24.3, the alpine user has no password but can become root via doas without entering one — the highest-risk scenario. By default, root stays protected by PermitRootLogin prohibit-password — unless it was switched to yes.

What's the real impact?

This is an authentication bypass, not remote code execution. But the effect is still serious: on an Alpine cloud image, getting a session on the alpine account usually means getting root via doas. Alpine Docker containers that don't expose SSH are not affected.

Am I exposed?

As root, one command settles it:

sshd -T | grep -i -E 'passwordauthentication|usepam'

You are not exposed if password authentication is off (passwordauthentication no) or PAM is on (usepam yes).

To hunt for a possible compromise, look for accepted password logins on accounts that have no password:

grep "Accepted password" /var/log/messages

Fixes

Updating is the simplest path:

apk upgrade -U -a
rc-service sshd restart

Alpine backported the fix to every branch, 3.16 through edge:

edge  : openssh 10.6_p2-r0
3.24  : openssh 10.3_p1-r2
3.23  : openssh 10.2_p1-r1
3.22  : openssh 10.0_p1-r11
3.21  : openssh 9.9_p2-r1
3.20  : openssh 9.7_p1-r6
3.19  : openssh 9.6_p1-r3
3.18  : openssh 9.3_p2-r4
3.17  : openssh 9.1_p1-r7
3.16  : openssh 9.0_p1-r6

If patching isn't possible (Alpine < 3.16, or a production constraint), disable password authentication after confirming your key login works:

# /etc/ssh/sshd_config
PasswordAuthentication no

Don't forget to rebuild and redeploy container images that carry an older openssh package.

Takeaways

• A critical flaw doesn't always come from a single component: here it's the interaction between musl and OpenSSH that opens the hole, each being "correct" on its own.
• musl + no PAM is a combo to watch: it's Alpine's default, and very common in container images.
• The most robust mitigation is timeless: key-based authentication, password disabled.

Sources: Alpine Linux advisory and Cycode analysis (CVE-2026-123158), November 5, 2026.