If you run Alpine Linux with sshd reachable from outside, put this down and update first: apk upgrade -U -a, then rc-service sshd restart. The second step is not optional, because upgrading the package does not replace the daemon that is already running.
OpenSSH released version 10.6p2 on 5 November 2026 with an urgent fix, and Alpine published its advisory the same day along with fixed packages for every branch back to 3.16. The flaw has been named *sshole, is tracked as CVE-2026-123158 and allows login to certain accounts without knowing the password. It was found by Özgün Kültekin of Wakefield.
What breaks
There is no single guilty line. Three reasonable decisions have been fitting together badly for years:
- The musl library caps the key its SHA-crypt functions accept at 256 bytes, and when something fails,
crypt()returns the string*rather than a null pointer. That dates from 2012. - On Unix, a
*in the password field has meant “this account does not log in with a password” for decades. It was assumed it could never match a real hash. - Since 2016, to avoid revealing which users exist (CVE-2016-6210),
sshdalso computes a hash in those cases, using the salt of another account on the system.
Together, those pieces mean that on a system with musl and no PAM, the error result from crypt() can be compared with the stored * and accepted. That is where the headline’s ten years come from: the OpenSSH piece is from 2016. Alpine’s advisory puts the problematic length between 257 and 1024 bytes, while the CVE record says 256 to 1024.
OpenSSH considers the root cause to lie outside its code, but has dealt with it on its side: the patch requires the stored hash to have a minimum length before accepting the comparison, so a * can no longer match.
Who is really affected
Alpine considers a machine vulnerable only if all of this is true at once:
- It uses the
openssh-serverpackage, built without PAM, oropenssh-server-pamwithUsePAM no. - It has
PasswordAuthentication yes, which is the default. - An account has
*in its password field: key-only users, directory users through musl-nscd, or thealpineuser in tiny-cloud images. - Another local account has a
$5$or$6$hash.
Outside Alpine, sources mention other musl systems such as OpenWrt, Buildroot and Yocto, always depending on how they are built and configured. If you maintain your own firmware, check rather than assume.
Not affected: glibc systems (Debian, Ubuntu, Fedora and the like), anything using PAM, systems with PasswordAuthentication no, containers that do not run sshd, accounts locked with !, and cloud images configured through cloud-init, which disables passwords.
Does it really give you root?
That claim has been repeated a lot on social media and needs some nuance. On Alpine, root has had * since 3.16, but the default PermitRootLogin prohibit-password protects it unless you have set PermitRootLogin yes.
The real problem is accounts that can reach root. The official 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 stop being safe as soon as any $6$ hash appears on the machine, for example when someone sets a console password.
Nor does any Alpine box qualify: an install with no $5$ or $6$ hash is out of scope, and the CVSS 3.1 vector scores it 8.1 (high) with high complexity. Even so, Alpine warns that the attack needs no retries and only requires reaching the port, so this is no reason to relax. CISA records that public proofs of concept already exist.
Fixed versions
| Alpine branch | Fixed openssh package |
|---|---|
| edge | 10.6_p2-r0 |
| 3.24 | 10.3_p1-r2 |
| 3.23 | 10.2_p1-r1 |
| 3.22 | 10.0_p1-r11 |
| 3.21 | 9.9_p2-r1 |
| 3.20 | 9.7_p1-r6 |
| 3.19 | 9.6_p1-r3 |
| 3.18 | 9.3_p2-r4 |
| 3.17 | 9.1_p1-r7 |
| 3.16 | 9.0_p1-r6 |
Alpine 3.21.10, 3.22.8, 3.23.8 and 3.24.4 already include the fixed package. If you build OpenSSH yourself, you need 10.6p2 or later.
What to do now
Update and restart the service:
apk upgrade -U -a
rc-service sshd restartIf you cannot update yet, disable passwords. First check that your key works, and keep a session open until you have tested a new login:
mkdir -p /etc/ssh/sshd_config.d
echo 'PasswordAuthentication no' > /etc/ssh/sshd_config.d/00-no-passwords.conf
sshd -t && rc-service sshd restart
sshd -T | grep -i passwordauthenticationThat directory is only read by default from Alpine 3.19 onward. On older releases, change the directive in /etc/ssh/sshd_config, and check any Match blocks too. The last command should print passwordauthentication no.
How to tell if someone got in
Accounts with no password should never show up with a password login, so start there:
grep 'Accepted password' /var/log/messagesIf key-only accounts or alpine appear, review doas use, newly created users, recent files and authorized_keys. If you cannot rule out access, Alpine recommends treating the machine as compromised, and the safe route is to reinstall it and rotate its credentials.
How we tested this
We checked the library’s behaviour, not the attack: we did not make any login attempt against sshd. Using a small C program that calls crypt() with a $6$ salt, on alpine:3.24 (musl 1.2.6-r3) a 256-byte key gives a normal hash and a 257-byte one returns *. On debian:13 (glibc), the 257-byte key still gives a normal hash and the 1024-byte one returns *0, an error that does not match an account’s *. That fits what the advisories say about glibc.
What this article says about versions and conditions comes from Alpine’s advisory, the OpenSSH release notes and the patch code.
There is more on the distribution on the Alpine Linux page, and to review your own server, see our guide to SSH keys and hardening sshd.