OpenSSH "SSHole" Flaw on Alpine and Other Small Linux Systems: Update and Restart SSH

If your business runs Linux servers, cloud machines or appliances that accept SSH logins, check whether any of them are built on Alpine Linux or another small Linux build that uses the musl library. On November 9, 2026, CISA added an OpenSSH flaw, CVE-2026-123158 (nicknamed "SSHole"), to its Known Exploited Vulnerabilities catalog. On affected systems, someone who can reach the SSH port can sign in without knowing a password.

The short version: on Alpine, run the OpenSSH update and then restart the SSH service, because installing the update does not replace the copy that is already running. If you cannot update right away, turn off password logins for SSH. Either step closes the hole.

What the flaw does

OpenSSH released version 10.6p2 on November 5 with what it calls a critical security workaround for Linux systems that use the musl C library with PAM (the standard Linux sign-in framework) turned off. According to the Alpine Linux security advisory, an attacker who knows the name of an account with no password set (shown as * in the password file, which is normal for key-only accounts) can send a very long password and be let in. It takes one connection and needs no retries.

The machine also has to have at least one other local account with a regular password hash, and password logins have to be turned on, which is the OpenSSH default. Alpine says one account with a password is enough to make every passwordless account reachable.

Security researchers report the flaw is being used in real attacks. Help Net Security reported that the threat intelligence firm Previdian confirmed an attacker gained root access on one of its Alpine test systems less than a day after the flaw became public, and Ars Technica reported further attacks seen by GreyNoise and watchTowr. CISA set a federal remediation due date of November 12, 2026.

Who is at risk

• Alpine Linux systems running the standard openssh-server package, which is built without PAM, or the PAM package with UsePAM no. Alpine says every release it checked is affected, from 3.16 through 3.24 and edge.
• Official Alpine cloud images (tiny-cloud) from 3.18.11 through 3.24.3. They ship an alpine user with no password that can become root. Alpine says they are safe on first boot but become exploitable once any password is set on the machine.
• Other musl-based builds that run OpenSSH without PAM. The researcher who found the flaw lists OpenWrt, Buildroot and Yocto among systems worth checking. These are common inside routers and other embedded devices, so ask your vendor if a device has SSH turned on.

Per Alpine and the researcher, these are not affected: systems built on glibc, such as Debian, Ubuntu and Fedora; setups that check passwords through PAM; the Dropbear SSH server; OpenBSD; containers that do not run an SSH server inside them; and any system with password logins turned off.

What to do this week

1. Find SSH servers that can be reached from the internet. Note which ones run Alpine or another musl-based build.
2. Update OpenSSH and restart SSH. On Alpine, update packages and restart the SSH service afterward. Alpine has published fixed packages for every branch from 3.16 to edge, including releases that no longer get regular updates.
3. If you cannot update yet, turn off password logins. Set PasswordAuthentication no and restart SSH. Before you do, confirm key-based login works so you do not lock yourself out.
4. Check for signs of a break-in. Alpine recommends looking in /var/log/messages for "Accepted password for" lines naming accounts that have no password, such as alpine, root or key-only users, and reviewing recent new users, authorized SSH keys and doas use. If a login cannot be ruled out, treat the machine as compromised.
5. Limit who can reach SSH. Where possible, allow SSH only from trusted networks or through a VPN.

Questions to ask your IT provider

1. Do any of our servers, cloud machines or appliances run Alpine or another musl-based Linux with SSH turned on?
2. Has OpenSSH been updated on them, and was the SSH service restarted afterward?
3. Are password logins for SSH turned off where they are not needed?
4. Have the SSH logs been checked for password logins to accounts that should not have one?