The scariest thing about this OpenSSH flaw is how little it takes to exploit. Tracked as CVE-2026-123158 and nicknamed SSHole, it lets a remote attacker log in to an account that should reject password logins. The attacker needs a password between 257 and 1,024 characters long and the name of a locked-down account. As watchTowr's Jake Knott put it, "the exploit is strikingly simple."
The bug was found by Ozgun Kultekin, a researcher at security testing firm Wakefield, and it has been sitting in the code for about 10 years. The OpenSSH maintainers shipped mitigations in the OpenSSH 10.6p2 emergency update on Thursday, though they insist the bug isn't actually in their code. My read: that's technically defensible, and it doesn't help anyone whose server is exposed. The problem sits in the interaction between OpenSSH and the musl C library.
Three unrelated changes that add up to a login bypass
No single change here looks dangerous. Each one solved a real problem at the time.
In 2012, musl's developers capped password length at 256 bytes, so attackers couldn't tie up a server by submitting huge passwords that had to be hashed during login. In the same change, musl's hashing function started returning an asterisk whenever it failed. Unix has used that asterisk since the 1980s to mark accounts where no password should ever match, meaning accounts with password login disabled at the system level.
In 2016, OpenSSH changed how it verifies passwords for accounts with no salt to hash against. It borrowed another account's salt, so attackers couldn't identify valid usernames by timing login responses. Then in 2022, Alpine set root's password field to an asterisk so SSH key logins would keep working.
Put those together and the failure path becomes obvious. An over-long password for a password-disabled account makes the hash call fail and return an asterisk. sshd compares that asterisk against the asterisk stored in the account's password field, finds a match, and grants the login.
Why Alpine cloud images are the main exposure
The prerequisites are narrow, but Alpine meets nearly all of them by default. Alpine uses musl, its standard OpenSSH package is built without PAM, and password logins are enabled out of the box. Debian, Ubuntu, and Fedora, which use glibc, aren't affected. Embedded systems running Dropbear instead of OpenSSH also fall outside the bug.
The bigger problem is the official Alpine cloud images published between versions 3.18.11 and 3.24.3. The default user, "alpine," has a disabled password and passwordless "doas" privileges. An attacker who logs in as that user can escalate to root, and the exposure becomes live as soon as an administrator sets a password for any other account on the box. That real password is what the attack needs in order to get going.
This isn't a repeat of the regreSSHion flaw from 2024, which affected a far wider set of systems. This one is confined to the musl world, but it needs no exploit engineering at all. That's what makes it worrying.
Knott expects attackers to move quickly. "Internet-exposed SSH servers are already being hammered by password guesses and brute-force attempts around the clock," he said. "Exploiting this vulnerability simply means those same attackers add a very long password attempt to that brute-force list. We'd be extremely surprised if we didn't see SSH brute-forcers attempting this by the weekend."
What to check and change now
Patch first. Alpine has released updated openssh packages, and the Alpine advisory says that if you can't update right away, you should disable password-based authentication in the OpenSSH configuration and move to key-based logins.
Then look for signs that someone already got in. An "Accepted password" entry in /var/log/messages for an account without a password, such as root, a key-only user, or the default alpine user, is a strong indicator of compromise. Alpine recommends reviewing doas usage, recently created users, and recently changed files on any exposed machine. Its advisory goes further: if a login can't be ruled out, treat the server as compromised. Kultekin also published a check script on GitHub that flags exposed servers and lists the accounts at risk.
The real lesson here is about defaults. Three reasonable decisions, made years apart in different projects, combined into a bypass that most administrators would never have predicted. Anyone running musl-based servers should audit where their password-disabled accounts sit and assume the brute-forcers have already added this to their list.
