I will update this story if OpenSSH, Alpine or CISA release new details.

◢What is SSHole?

On Linux, an account can have its password disabled: an asterisk (*) is stored instead, and the idea is that the account can only be reached with an SSH key, or not at all. This is common for service accounts and on many servers where people only work with keys.

As The Hacker News explains, the problem appears when an attacker sends a very long password, between 257 and 1,024 bytes. On systems that use the musl C library, the function that hashes the password fails at that length and returns, of all things, an asterisk. OpenSSH compares that asterisk with the one stored for the account, sees a match and lets the attacker in. The root cause is a 2016 patch that fixed a different bug (CVE-2016-6210).

The flaw was found by researcher Ozgun Kultekin, is rated 8.1 out of 10 and is fixed in OpenSSH 10.6p2, released on November 5.

◢Who is affected, and who is not?

According to The Hacker News, it only affects Linux systems running OpenSSH on musl with PAM disabled (PAM is the component that checks passwords on many distributions). The default OpenSSH server configuration on Alpine Linux meets those conditions.

It does not affect glibc-based distributions, which cover most servers (Debian, Ubuntu, Red Hat and their derivatives), systems that check passwords through PAM, Dropbear, or non-Linux systems. Nor does it bypass a normal password: there has to be at least one account with the asterisk instead of a password.

What the attacker gets is that account's permissions. If that account can become an administrator without a password, the result is full control of the machine, as BleepingComputer notes.

◢Is it being exploited?

Yes. According to BleepingComputer, a public proof of concept appeared about four hours after the fix, attempts started that same day, November 5, and successful attacks followed the next day.

Previdian confirmed root access on an Alpine Linux honeypot and, as of November 8, counted 20 attempts from 13 IP addresses in nine countries, according to The Hacker News. GreyNoise recorded its first successful attack on November 7 and 16 successful attack chains from six IP addresses in total, according to BleepingComputer. The attackers looked around the machine, tried to read password hashes and root's SSH keys, and changed authorized_keys files to keep their access. In one case they installed a remote control program written in Python, although its command server was not responding.

watchTowr has linked the exploitation to botnets and cryptomining, the same outlet reports. There is no official attribution to any group or country. CISA lists use in ransomware campaigns as unknown and has given US federal agencies until November 12 to fix it.

◢How do I know if my company is affected?

The useful question for the technical team is: do we have machines running Alpine Linux, or another musl-based distribution, with the SSH server reachable? That includes Alpine-based containers that ship the SSH server, and older images that are still running too. An image built months ago does not patch itself.

If you are not sure what systems you have, ask whoever runs your servers, or the provider that maintains them, today. If everything is Ubuntu, Debian or Red Hat, this particular flaw does not affect you.

◢What to do now

• ▹Update OpenSSH to 10.6p2 or your distribution's fixed package, and restart sshd so the change takes effect.
• ▹If you cannot update today, turn off SSH password logins (PasswordAuthentication no in the sshd configuration) and use keys only.
• ▹Check the logs. Alpine recommends looking in /var/log/messages for sshd lines reading "Accepted password for" on accounts that have no password (alpine, root or any key-only user).
• ▹On exposed machines, review doas use, users and files created in recent days, and authorized keys. Alpine is blunt about it: if you cannot rule out a login, treat the machine as compromised.
• ▹Rebuild Alpine-based container images that include sshd so they ship the fixed package.

◢What to learn from this

What stands out about SSHole is the speed: hours from the fix to the first public proof of concept, and less than two days to the first recorded successful attack. It is the same pattern we saw with the SonicWall VPN flaw. The gap between a patch coming out and someone abusing the bug is no longer measured in weeks.

The other lesson is simple: an SSH server open to the internet that accepts passwords is a door worth closing even when there is no known flaw. Key-only logins, ideally only through a VPN or from specific addresses, would have made this attack useless.

And knowing what systems you have is the foundation for everything else. Many companies find out from an advisory like this one that they have machines nobody remembered. If you want your team to understand why this matters, that is what I work on in my cybersecurity training.