OpenSSH flaw on Alpine Linux lets attackers log in without a password

On 5 November 2026 the OpenSSH project released an out-of-band version 10.6p2 and Alpine Linux published fixed packages the same day. The reason is an authentication bypass: an attacker who can reach your SSH port logs in as an account with no password set, without knowing any password. Since 6 November the threat intelligence firm Previdian has observed exploitation attempts on its sensors and says an attacker gained root access on a honeypot running Alpine Linux. Do not wait with the update.

What happened

OpenSSH is the most widely used server for remote access to Linux machines. Alpine Linux is a small Linux distribution built on the musl libc library and busybox, often used as a base for containers and small cloud images.

When sshd is built without PAM support, it checks a password by hashing the submitted text with the crypt() function of the C library and comparing the result with the stored password field. For an account whose field is too short to hold a salt (the random prefix of a hash), sshd borrows the salt of another account. In musl, however, crypt() returns the string * as an error indicator when the password is longer than 256 bytes, and that is exactly what the password field contains for every account with no password. The two strings match and sshd accepts the login.

According to the Alpine Linux advisory, the attacker only needs the name of such an account and at least one other account on the machine with a $5$ or $6$ password hash. A password between 257 and 1,024 bytes works on the first attempt, with no retries. A single account with a password therefore opens up every account without one.

What makes this worse than it looks is where accounts without passwords come from. They are common exactly where people log in with keys: service accounts created without a password, users from a directory service through musl-nscd, and the alpine account in the official cloud images. According to the Alpine Linux advisory that account also has passwordless doas, so an attacker can go on to become root. The flaw was reported by Özgün Kültekin of Wakefield. Severity ratings differ between sources: the CVE-2026-123158 record gives a CVSS score of 8.1, the OpenSSH project describes it in the release notes as a critical security issue, and the VulDB database gives a CVSS score of 10.0. NVD has not analysed the flaw yet.

Exploitation attempts appeared quickly. Previdian, which collects data from its own sensors and honeypots, says it recorded the first attempt less than nine hours after the CVE record was published and confirmed root access on a honeypot running Alpine Linux and OpenSSH. On 7 November 2026 its page for CVE-2026-123158 listed 17 attempts from 11 IP addresses in eight countries. These are still small numbers from a single source rather than a wave of attacks, and the flaw is still not in the CISA catalogue of exploited vulnerabilities. According to Previdian the attackers sent oversized passwords and then ran the commands id, uname and hostname over non-interactive sessions, the usual way of finding out where they have landed.

Does this affect you?

You are affected if all of the following is true:

• you run sshd from the Alpine openssh-server package, which is built without PAM, or openssh-server-pam with UsePAM no,
• PasswordAuthentication is yes, which is the OpenSSH default,
• the machine has an account whose password field is *, for example a service account without a password, a user from a directory service, the alpine account from the cloud images, or root, which is only reachable with PermitRootLogin yes,
• at least one local account has a $5$ or $6$ password hash.

Alpine Linux lists as affected every release it checked, 3.21 to 3.24 and edge, plus the older branches 3.16 to 3.20 that no longer receive regular updates. Fixed packages were published for every branch back to 3.16.

You are not affected if you do not run sshd in the container at all, if you have PasswordAuthentication no, if you use openssh-server-pam with UsePAM yes, if no account on the machine has a password hash, or if the image is configured by cloud-init, which writes PasswordAuthentication no itself. Distributions built on the glibc library do not have the flaw. Red Hat states in its CVE record that its products are not affected, because it builds OpenSSH against glibc and with PAM.

Cloud images deserve special attention. According to Alpine Linux, the official tiny-cloud images (qcow2, VHD and AMI) from 3.18.11 to 3.24.3 ship an alpine account with the password field *. They are safe on first boot and become exploitable the moment the first $6$ hash appears on the machine, for example when an administrator sets a console password or user data creates an account with a hash. Images from 3.21.10, 3.22.8, 3.23.8, 3.24.4 and later already contain the fixed package. On earlier ones you have to act on every running instance.

What to do now

Update the package and then restart the daemon. The update itself does not replace a running sshd, so a machine can show a fixed version in its package database while an older process still serves SSH.

apk upgrade -U -a
rc-service sshd restart

These versions of the openssh package contain the fix:

Point releases 3.21.10, 3.22.8, 3.23.8 and 3.24.4 already include the fixed package.

If you cannot update right away, turn off password logins: set PasswordAuthentication no and restart sshd. Before that, make sure your key login works and keep your current connection open until you have tested a new one. Alpine Linux gives ready commands for this in the advisory, including a file in /etc/ssh/sshd_config.d, which branches older than 3.19 ignore.

How to tell whether you have been attacked

Alpine Linux recommends going through /var/log/messages and looking for sshd lines reading Accepted password for an account that has no password, that is alpine, root or any key-only account. On exposed machines review the use of doas and recently created users, files and keys in authorized_keys. If you cannot rule out a login, treat the machine as compromised.

Previdian names 89.116.89.18 as the source of the first attempts. Blocking a single address is not enough, as the same firm reports attempts from ten further addresses, but in your logs it can help you see when someone started taking an interest in you.

Cannot keep track of all this?

We publish this roundup every week. Following it is only the first step. The harder part is knowing which vulnerabilities affect you specifically, in what order to deal with them and who in the company is responsible.

That is where we help: security assessment and vulnerability management · outsourced security manager · technology selection and deployment

Informal consultation · Dealing with an incident right now?

We will tell you straight what is worth addressing first. The initial consultation is free of charge.

Sources: Alpine Linux, security advisory on the password authentication bypass · OpenSSH, release notes for 10.6p2 · Red Hat, record for CVE-2026-123158 · VulDB, rating of CVE-2026-123158 · Previdian, observed exploitation attempts for CVE-2026-123158 · CISA, Known Exploited Vulnerabilities catalogue · Help Net Security, exploitation shortly after disclosure