Nine hours. That is how long it took from CVE publication to the first exploitation attempt.
The vulnerability is CVE-2026-123158, and it now has a name: SSHole. It allows an unauthenticated attacker to log into accounts that have no password set, on Linux systems running OpenSSH with musl and PAM disabled. Alpine Linux's default configuration is squarely in that category.
Previdian confirmed successful root access on a honeypot running Alpine Linux and OpenSSH. The attack works on the first try, with a single connection, using an oversized password.
The Exploitation Timeline
Previdian's data is specific, and the speed is the story.
|
Metric |
Detail |
|
First exploitation attempt |
Less than nine hours after CVE publication |
|
Total attempts recorded |
Eight |
|
Source IP |
89.116.89[.]18, geolocated to Japan |
|
Confirmed result |
Root access on an Alpine Linux honeypot |
|
Commands executed |
id, uname, hostname through non-interactive SSH sessions |
Ryan Dewhurst, founder and CEO of Previdian, confirmed the activity. The attacker used oversized passwords to bypass authentication, then ran reconnaissance commands to learn about the environment.
That is the standard first move. You get in, you figure out what you landed on, then you decide what to do next.
Why the Flaw Works
The mechanism is rooted in a patch from 2016.
OpenSSH fixed a username enumeration vulnerability tracked as CVE-2016-6210. As part of that fix, when the password field for an account is empty, sshd borrows the salt from another account that has a real hash.
On musl, crypt() refuses passwords longer than 256 bytes and returns * on failure. That asterisk matches the * stored in the password field of an account with no password.
The comparison succeeds. The login goes through.
An attacker needs a password between 257 and 1,024 bytes long. That is the entire requirement.
What SSHole Does Not Do
This is worth stating clearly, because the name sounds worse than the scope.
The attack requires at least one account with * as its password hash. It does not bypass passwords on accounts that have valid password hashes.
If you have a password on every account, and no passwordless accounts exist, SSHole has nothing to exploit. It is not a universal bypass. It is a very specific one that happens to hit a very common default configuration.
Who Is Exposed
|
System Type |
Affected? |
|
Alpine Linux with default openssh-server |
Yes |
|
Other musl-based distributions with PAM disabled |
Yes |
|
glibc-based Linux distributions |
No |
|
Systems using PAM for password checks |
No |
|
Non-Linux systems |
No |
|
Dropbear SSH |
No |
Alpine's base image ships root:* by default, and the alpine user in cloud images built with tiny-cloud has passwordless doas. Those are the accounts attackers go after.
The Business Impact
Safe Security framed the risk accurately. A successful SSHole attack grants access with the compromised account's existing permissions, which means the impact depends entirely on what that account can reach.
Unauthorized SSH access is the immediate problem. The downstream problem is that attackers can then reach deployment credentials, application secrets, and connected infrastructure. From there, lateral movement and service disruption become available.
If the compromised account is root, everything on that machine is exposed.
How to Fix It
Install OpenSSH 10.6p2 or your distribution's patched package. Then restart sshd. The restart is not optional. The running process keeps the old binary until you do.
On Alpine:
apk upgrade -U -a
rc-service sshd restart
If you cannot update yet, set PasswordAuthentication no. That closes the attack path entirely. Confirm your key login works first, and keep your current session open until a new login succeeds.
What to Check for Compromise
Alpine's guidance is specific. Look in /var/log/messages for sshd lines reading Accepted password for an account that should not accept password logins. That means alpine, root, or any key-only user.
Also review:
- doas usage
- Recently created users
- Recently modified files
- Recently added authorized_keys entries
Alpine's conclusion is direct. If you cannot rule out a login, treat the machine as compromised.
FAQ
What is SSHole?
It is the codename for CVE-2026-123158, a vulnerability in OpenSSH that allows an unauthenticated attacker to log into passwordless accounts on Linux systems running OpenSSH with musl and PAM disabled.
How does the attack work?
An attacker supplies a password between 257 and 1,024 bytes. On musl, crypt() returns * when the password is too long, which matches the * stored in the password field of a passwordless account. The login succeeds.
Which systems are affected?
Alpine Linux with default openssh-server is the primary target. Other musl-based distributions with PAM disabled are also affected. glibc-based systems, PAM-enabled systems, non-Linux systems, and Dropbear are not.
Has it been exploited in the wild?
Yes. Previdian recorded the first attempt less than nine hours after CVE publication, with eight total attempts from an IP geolocated to Japan. It confirmed successful root access on a honeypot.
What commands did the attacker run?
id, uname, and hostname through non-interactive SSH sessions. That is standard reconnaissance.
Does SSHole bypass real passwords?
No. It only works on accounts that have * as their password field, meaning no password is set. Accounts with valid password hashes are not affected.
What version fixes it?
OpenSSH 10.6p2, or your distribution's patched package. Restart sshd after installing.
What if I cannot patch immediately?
Set PasswordAuthentication no, verify with sshd -t, and restart sshd. Confirm your key login works before you make the change.
How do I check whether I was compromised?
Look in /var/log/messages for Accepted password entries for accounts that should not accept password logins. Also review doas usage, new users, modified files, and added authorized_keys. If you cannot rule out a login, treat the machine as compromised.
