Hackers are exploiting the SSHole flaw in OpenSSH to break into Alpine Linux servers

Attackers are already using SSHole (CVE-2026-123158, severity 8.1 out of 10), a flaw in OpenSSH that lets them log in to some Linux servers with any password longer than 256 characters. It works on systems built on the musl C library, Alpine Linux first of all. Threat intelligence firm GreyNoise recorded the first successful break-in on November 7 at 00:46 UTC, about 40 hours after the fix came out. After logging in, intruders looked for passwords and keys, added their own SSH keys and in one case installed a remote control agent, BleepingComputer reports.

How the bypass works

On Linux, a * in the password field of /etc/shadow means the account cannot be logged into with a password at all. Alpine uses it for root and for key-only users. The researcher Özgün Kültekin of Wakefield, who reported the bug, traced it back to a 2012 change in musl: when its password hashing function fails, it returns * instead of an error. It fails on any password over 256 bytes. So a very long password "hashes" to *, which matches the locked account, and sshd lets the attacker in. With PAM enabled, sshd never compares the hashes this way, so those systems are safe.

The attack needs four things at once: sshd built against musl, PAM disabled, password authentication enabled and at least one account with * in its password field. On Alpine, the first three are the defaults of the openssh-server package, and root has had * since version 3.16. Alpine's official AWS and Azure images also have a default alpine user that can run commands as root without a password, so a login there gives full control.

What the attackers did

OpenSSH released version 10.6p2 with the fix on November 5. The researcher's write-up appeared the same day, and exploit code was on GitHub within an hour of it. GreyNoise saw 16 successful attack chains from six IP addresses against systems it monitors and stresses that this is only part of the activity. The intruders checked whether they were inside a container, queried cloud metadata services, tried to read root's SSH keys and /etc/shadow, and wrote their keys into authorized_keys for root and the alpine user to keep access.

One group gained root, changed the system's DNS settings, started a second, hidden SSH server and installed TAC Agent, a Python program with comments and messages in Chinese that can run commands and move files. It never managed to register with its control server, tac.vpnla[.]org, and received no tasks. Security firms Previdian and Defused also recorded attempts, and watchTowr linked the flaw to botnet and cryptomining activity.

How to check your server

• Find out what the server runs: cat /etc/os-release. If it is Alpine or another musl system, keep reading. Ubuntu and Debian servers are not exposed to this bug.
• Update: apk upgrade openssh on Alpine. Patched packages are out for branches 3.19 to 3.24 and edge, per the Alpine security tracker.
• Turn off password login if you use keys: PasswordAuthentication no in the sshd config, then restart sshd. This also closes the hole before patching.
• Look for traces: successful password logins (grep "Accepted password" /var/log/messages) for accounts that have * in /etc/shadow, unknown keys in authorized_keys, the files /opt/py3/tac_agent.py and /etc/init.d/tac-agent, changes to /etc/hosts and /etc/resolv.conf, and an extra SSH server on a non-standard port (ss -tlnp lists listening ports).
• If you find any of that, treat the server as compromised: reinstall it and change every password and key that was stored on it.

This matters for anyone who runs a personal VPN on a cheap VPS: small Alpine images are popular for that. Most home routers with OpenWrt use Dropbear for SSH and are not affected unless the owner swapped it for OpenSSH. Our VPS hardening guide already recommends key-only SSH login, and that setting blocks this attack.