SSHole Exploited in the Wild Hours After Disclosure, Honeypot Gets Rooted
A newly disclosed OpenSSH vulnerability is already being weaponised. Less than nine hours after CVE-2026-123158 went public, threat intelligence firm Previdian logged the first exploitation attempt, and confirmed successful root access on a honeypot running Alpine Linux. Someone moved fast.
The flaw, dubbed SSHole (or *sshole, if you prefer the more colourful version), carries a CVSS score of 8.1. It affects Linux systems running OpenSSH on the musl C library with Pluggable Authentication Modules disabled. Alpine Linux's default OpenSSH configuration ticks all those boxes.
The mechanics are genuinely odd. Discovered by researcher Ozgun Kultekin, the bug traces back to a 2016 patch that was supposed to fix a username enumeration issue (CVE-2016-6210). That patch introduced subtly broken password-handling logic. When an oversized password, somewhere between 257 and 1,024 bytes, causes a hashing operation to fail, OpenSSH returns an asterisk. The sshd daemon then compares that asterisk against the account's stored password field. If the account has no usable password, its hash is already stored as an asterisk. The comparison succeeds. You're in.
No stolen credentials. No SSH keys. Just a deliberately long garbage string and a logic quirk that's been sitting quietly in the codebase for nine years.
It's worth being precise about scope. This only works on accounts where the password field is literally an asterisk, meaning accounts deliberately configured without a usable password. It does nothing against accounts with real password hashes. So it's not a skeleton key, but it's not nothing either.
Root is frequently configured this way on minimal server setups. Alpine being exhibit A.
Previdian's telemetry shows eight exploitation attempts from a single IP geolocated to Japan (89.116.89[.]18). The attacker ran non-interactive SSH sessions and issued basic reconnaissance commands: id, uname, hostname. Classic post-compromise footprinting.
The good news is the fix exists. OpenSSH 10.6p2 addresses it. Update, then restart sshd. The bad news is that if you were running a vulnerable setup before patching, you may have already had uninvited guests.
Alpine is advising users to grep /var/log/messages for sshd entries showing "Accepted password" on accounts that shouldn't be accepting passwords at all. Root, alpine, and any key-only user fall into that category. If you find suspicious entries, check for recently created users, new authorised keys, and doas usage. And if you can't definitively rule out unauthorised access, treat the box as compromised.
Dropbear users, glibc-based distributions, and anything running PAM-based authentication are not affected. Cold comfort if you're running Alpine in production and haven't patched yet.