senn-techAlpine's OpenSSH flaw: a long password opens passwordless accounts, and we checked 36 hosts
Alpine Linux published an OpenSSH security update on 5 November 2026. Someone who connects to an Alpine server over SSH and sends a password of 257 to 1024 bytes gets in without the right password, provided a few conditions hold. We read our own Alpine systems the same day: 36 hosts, 21 of which still allow password login, and exactly one host meets all the conditions for the attack. It is reachable only from the internal network. All 36 are patched now, and we did not try the attack anywhere.
What the flaw is
The flaw is a login bypass in OpenSSH on Alpine Linux. For keys longer than 256 bytes, the musl C library returns the error value * instead of computing a hash. An SSH server built without PAM compares that value to the password field of the account. Accounts without a password, such as key-only accounts, have * there too. The comparison matches and the attacker is in, even though only keys were supposed to work.
Alpine lists four conditions for exploitation. The attacker can reach the SSH port. The server runs without PAM, meaning the regular openssh-server package, or openssh-server-pam with UsePAM no. PasswordAuthentication is yes, which is also the default when the line is missing. And the machine has at least one account with * in the password field plus at least one other account with a $5$ or $6$ hash. openssh-server-pam with UsePAM yes is not affected. No CVE number had been assigned on the day of publication, and the flaw was reported by Özgün Kültekin of Wakefield. The Hacker News covers it under the name "sshole".
The fix and what comes after it
The fix is in the openssh package. The advisory lists a revision per branch: 10.2_p1-r1 for 3.23, 10.3_p1-r2 for 3.24, 10.0_p1-r11 for 3.22 and 9.9_p2-r1 for 3.21, with further revisions for 3.16 to 3.20 and 10.6_p2-r0 for edge. The point releases 3.21.10, 3.22.8, 3.23.8 and 3.24.4 already contain it. After updating the packages, run rc-service sshd restart, because an upgrade does not restart a running sshd. If you cannot update right away, set PasswordAuthentication no and check with sshd -T that the line passwordauthentication no appears. Confirm a key login in a second session first.
What we measured
We measured on 5 November 2026 over ssh from a workstation, read-only. On each host we read the package revision, the effective setting with sshd -T, and the account list with the markers * and $5$ or $6$, without displaying any hash. Every host ran Alpine 3.23.7 with openssh-server 10.2_p1-r0 and no PAM package.
| Group | Hosts | Password login | Account with * and hash account | Result |
|---|---|---|---|---|
| Company network | 20 | yes | one host, two accounts with * | one host meets all conditions |
| Homelab | 14 | no | not checked | not exploitable |
| Log server | 1 | no | not checked | not exploitable |
| Other container | 1 | yes | root has *, no account with a hash | not exploitable, patched anyway |
| Total | 36 | 21 yes, 15 no |
Own measurement of 5 November 2026, Alpine 3.23.7, openssh-server 10.2_p1-r0.
Of the 20 company hosts with password login, 19 had no account with *. The host where it matched is an internal service host with two service accounts. Both have * in the password field and a login shell, and root has a $6$ hash. All four conditions were met there. The host cannot be reached from outside, but inside the network any machine that could reach port 22 could have reached it.
Our first pass had rated this host as not affected, on the grounds that the two accounts were probably key-only. That is the attack case, not its opposite. Only sshd -T and a look at /etc/passwd corrected it.
Why the nightly update run would not have been enough
Our fleet updates through a nightly run with one command per host. Of 39 Alpine entries, 38 ran apk upgrade, and the 39th calls its own script that does the same. None restarted sshd afterwards. The packages would have been upgraded overnight, and the server with the flaw would have stayed in memory until its next reboot. Since 5 November all 39 entries carry sshd -t && rc-service sshd restart after the upgrade. The config check comes first, so a typo cannot take a server off the network. We ran the new step on one host and confirmed it with a fresh login.
Anyone who runs containers and hosts side by side knows the pattern: a package update is not a running service with the new code. How such a run keeps going when a host fails is covered in Patch run: one host stops the fleet, and the sequence of a fleet check after a flaw is in curl 8.23.0: fleet check.
What we did not check
Several entries in our SSH configuration point to hosts that no longer exist or do not answer. We found the Alpine hosts through our SSH list, not through an inventory of the virtualisation layer, so a host without an entry there would have escaped us. For systems you run yourself, Alpine's text applies: if you have openssh-server without PAM and PasswordAuthentication yes, you need the fix or the workaround.
How to check your own estate
Three commands cover one host: apk info -v openssh-server shows the revision, sshd -T | grep -i passwordauthentication the effective setting, and awk -F: '$2=="*"{print $1}' /etc/shadow lists the accounts with *. The last command prints user names only. If sshd -T shows no, the attack path is closed. If it shows yes and there is an account with *, that host goes first. This kind of fleet check is part of our IT support work, more under IT operations. The topic belongs to Security and privacy, and the basics of a patch routine for small companies are in Patch management for SMEs.
Further reading
Primary source
- Alpine Linux, OpenSSH password authentication bypass, 5 Nov 2026: alpinelinux.org
Independent report
- The Hacker News, 5 Nov 2026, report on the finding under the name sshole. The site rejects requests from scripts, so there is no link here.
Am I affected if I only use Alpine in containers?+
Only if the container runs an sshd. The flaw sits in the SSH server combined with the musl C library. A container without its own sshd, like most application images, does not have this attack path. apk info -e openssh-server inside the container tells you.
Is setting PasswordAuthentication to no enough?+
As a stopgap, yes. Alpine names exactly this setting as the workaround, and afterwards sshd -T prints the line passwordauthentication no. The real fix is the openssh package at the revision listed for your branch, and sshd has to be restarted after the upgrade.
Why does an update not restart the SSH server?+
apk upgrade replaces the files on disk, but a running sshd keeps the old program in memory. Alpine therefore says to run rc-service sshd restart after the upgrade. Until 5 November our nightly update run did not include that step.