SSHole OpenSSH Bug Opens Password-Disabled Accounts on Alpine

A ten-year-old bug in the way OpenSSH and the musl C library handle failed password hashes lets a remote attacker log into accounts that were deliberately configured to have no usable password — by sending a single, absurdly long password. The flaw, tracked as CVE-2026-123158 and nicknamed SSHole (or *sshole), carries a CVSS score of 8.1 and was addressed in an emergency OpenSSH 10.6p2 update released Thursday. It was discovered by Ozgun Kultekin, a researcher with security testing firm Wakefield, according to CSO Online.

This would be a footnote if it lived anywhere other than musl. But musl is the C library behind Alpine Linux, the minimalist distribution that underpins a huge share of cloud Docker images, plus a long tail of embedded systems. Alpine's default OpenSSH build meets every condition for the exploit straight out of the box, and its official cloud images ship a password-disabled alpine user holding passwordless doas privileges — a one-step escalator to root. Nor is exploitation theoretical: threat intelligence firm Previdian told The Hacker News it observed the first attack attempt less than nine hours after the CVE was published, and confirmed successful root access on an Alpine honeypot.

The primitive: 257 characters of anything

Jake Knott, head of threat intelligence at watchTowr, put it bluntly in comments to CSO Online: the exploit for a flaw in something as prevalent as OpenSSH amounts to nothing more than sending a long password — a string of A characters will do. On affected systems, he said, the whole technique is a password between 257 and 1,024 characters long.

That's the whole attack. No race conditions, no heap grooming, no shellcode — and per Ars Technica, it works on one connection, every time, with no retries. Compare that with 2024's regreSSHion, the last big OpenSSH scare, which demanded genuine exploit engineering; SSHole demands a copy-pasted string of A's. The one thing it categorically cannot do is bypass a real password: as The Hacker News notes, the bug only fires on accounts whose password field is an asterisk, so accounts with valid password hashes are immune to this specific trick.

Three innocent changes, one fatal asterisk

The bug is a systems-integration accident assembled from three changes made years apart, each defensible in isolation. In 2012, musl's developers capped password length at 256 bytes so attackers couldn't tie up servers by submitting enormous passwords that each needed expensive hashing. At the same time, they made musl's password-hashing function return an asterisk (*) whenever it fails — and the asterisk is exactly the character Unix has used since the 1980s to mark accounts where no password should ever match.

In 2016, OpenSSH patched a username-enumeration bug (CVE-2016-6210) by borrowing another account's salt when checking passwords for accounts whose own field offers nothing to hash against — a fix meant to stop attackers from guessing valid usernames via timing differences. Then in 2022, Alpine switched root's password field to an asterisk so SSH key logins would keep working for it. Stack the three together and the chain assembles itself: an attacker sends a 257-plus-byte password for a password-disabled account, musl's hash attempt fails and returns *, sshd compares that against the * stored in the account's password field, the two match, and the door swings open.

$ ssh alpine@target        # password: 300 x 'A'
# musl crypt() fails on >256 bytes -> returns "*"
# /etc/shadow stores "*" for the alpine account
# "*" == "*"  ->  sshd logs: Accepted password for alpine

For the record, the OpenSSH maintainers argue the flaw isn't in their code — the failure lives in musl's error-handling — but they shipped a mitigation in 10.6p2 anyway. From a defender's seat, the finger-pointing matters less than the patch.

What's exposed — and what isn't

Five preconditions must all hold for SSHole to work, and the list doubles as your scoping checklist:

• The distribution is built on musl, not glibc — which excludes Debian, Ubuntu, Fedora and most mainstream server distros.
• The SSH server is OpenSSH, not an alternative like Dropbear (common on embedded builds).
• OpenSSH was compiled without PAM support — Alpine's standard package is built exactly this way.
• Password authentication is enabled — again the Alpine default.
• The attacker knows the name of an account with an asterisk in its password field — and at least one account with a real (SHA256/SHA512-hashed) password exists on the system.

That last condition, surfaced by Ars Technica, has a nasty implication for Alpine's official cloud images. Between versions 3.18.11 and 3.24.3 those images ship the password-disabled alpine account with passwordless doas — but they only become exploitable once an administrator sets a password for any other account, because a legitimate account with a real hash must exist for the borrowed-salt code path to engage. The moment someone does that routine bit of setup, the image is wide open, and the alpine login converts straight to root. Other musl-based platforms may be affected under the same configuration, per Ars. Kultekin has published a check script on GitHub that identifies exposed servers and lists the at-risk accounts — run it before your change window, not after.

Exploitation: confirmed on a honeypot, expected everywhere

Here's what is confirmed, and it's narrow: Previdian observed eight exploitation attempts from a single IP address, 89.116.89[.]18, geolocated to Japan, and confirmed the attackers achieved root on a honeypot running Alpine Linux and OpenSSH. "The observed source IP, 89.116.89[.]18, used oversized passwords to bypass authentication and ran reconnaissance commands including id, uname and hostname through non-interactive SSH sessions," Ryan Dewhurst, Previdian's founder and CEO, said in a statement to The Hacker News.

A honeypot hit is not evidence of enterprise compromise — but the economics argue for assuming mass spraying. Knott's point is that internet-exposed SSH servers already endure password guessing and brute-force attempts around the clock, and exploiting SSHole requires nothing more than adding one very long password to an existing brute-force list; watchTowr would be extremely surprised if brute-forcers weren't attempting it within days. Safe Security, meanwhile, flagged what comes after the login: "While unauthorized SSH access is the immediate impact, attackers may also gain access to deployment credentials, application secrets, and connected infrastructure, potentially enabling lateral movement or service disruption."

Detection: hunt for the impossible login

SSHole leaves a beautifully loud fingerprint: a successful password authentication for an account that has no password. An "Accepted password" line in /var/log/messages for root, the alpine user, or any key-only account is, per CSO Online, a strong sign of compromise — such an event should be impossible on a healthy system. Alpine's own advisory, as reported by The Hacker News, tells defenders to search /var/log/messages for sshd entries showing an accepted password for an account that has none — the alpine account, root, or any key-only user — and to review doas usage along with recently created users, files and authorized keys on exposed machines. The advisory's bottom line: if you cannot rule out a login, treat the machine as compromised.

While unauthorized SSH access is the immediate impact, attackers may also gain access to deployment credentials, application secrets, and connected infrastructure, potentially enabling lateral movement or service disruption. — Safe Security, as quoted by The Hacker News

One caveat for your hunt: because musl bins anything over 256 bytes before hashing, the malicious attempts may not look exotic in logs — the authentication result does. Alert on the impossible success, not on password length.

Mitigation, and the container-shaped elephant in the room

The fix itself is easy: install OpenSSH 10.6p2 or your distribution's patched openssh package (Alpine has released emergency updates) and restart sshd. If you can't patch this week, Alpine's recommended workaround is to disable password authentication entirely and move to key-based login:

# /etc/ssh/sshd_config — the workaround Alpine recommends if you can't patch
PasswordAuthentication no
# then set up key-based auth and restart sshd

The harder work is inventory. Patching your servers and calling it done misses the actual blast radius, because Alpine's real footprint is the container base image. Any image derived from an affected Alpine version that runs sshd — for debugging, for legacy deploy tooling, for reasons nobody remembers — is a potential open door, and most organisations have no reliable list of which of their running containers even contain an SSH daemon. This is the same class of problem we saw when a CVSS 10 flaw in LXD and MicroCloud enabled trusted-client impersonation: container infrastructure quietly inherits trust assumptions nobody re-examined.

So the longer-term fix is a pipeline question, not a patch question. Sweep your registries and running pods for sshd binaries, rebuild anything based on the affected Alpine cloud image range from a patched base, and ask the uncomfortable question of why a container needs an interactive SSH server at all. Alpine-based ecosystems have already proven fragile under pressure — a GitLab regex RCE landed on CISA's KEV in the aftermath of an attack on Alpine infrastructure — and a ten-year-old authentication bypass that needs one fat password is exactly the kind of bug that brute-force botnets absorb into their wordlists and never remove. Patch fast, grep your logs for logins that shouldn't exist, and treat any host where you can't rule one out as compromised. That last part is Alpine's own advice, and it's the correct paranoia.