Hackers Exploit OpenSSH SSHole Flaw Hours After Disclosure

âš¡ TL;DR
Threat actors started exploiting CVE-2026-123158, nicknamed SSHole, within nine hours of its publication, and a honeypot running Alpine Linux handed one attacker root access, Previdian said. The bug lets an unauthenticated attacker log in to accounts with no usable password by sending an oversized password to OpenSSH on musl-based Linux with PAM disabled. OpenSSH 10.6p2 fixes it.

Threat actors began exploiting the OpenSSH SSHole flaw within nine hours of its CVE being published, and a honeypot running Alpine Linux granted an attacker root access, according to security firm Previdian. The vulnerability, tracked as CVE-2026-123158, lets an unauthenticated attacker log in to accounts that have no usable password on Linux systems running OpenSSH against the musl C library with Pluggable Authentication Modules disabled — a group that includes Alpine Linux’s default OpenSSH server configuration.

OpenSSH SSHole flaw

The bug carries a CVSS score of 8.1 and has been nicknamed SSHole. It requires no stolen credentials and no stolen SSH keys.

Nine Hours From Disclosure to Exploitation

Previdian said it confirmed successful root access on a honeypot it was running with Alpine Linux and OpenSSH. Its telemetry recorded eight exploitation attempts from a single IP address geolocated to Japan.

Ryan Dewhurst, founder and chief executive of Previdian, said the source address, 89.116.89[.]18, used oversized passwords to bypass authentication and then ran reconnaissance commands including id, uname and hostname through non-interactive SSH sessions — the kind of quick fingerprinting an intruder uses to work out what machine they have landed on and with what privileges. The sequence of events on the Alpine Linux honeypot, from CVE publication to working exploitation in under nine hours, was reported by news.lavx.hu, citing The Hacker News.

How the OpenSSH SSHole Flaw Works

The attack is unusually simple. An attacker sends a password between 257 and 1,024 bytes long. That oversized input causes the password-hashing operation to fail, and the failure returns an asterisk.

That asterisk is the same marker OpenSSH uses to indicate an account whose password has been disabled at the system level. sshd then compares the failed hash result with the asterisk stored in the target account’s password field, finds a match, and treats the login as successful.

The consequence is narrow but serious. The attack works only on accounts whose password field contains an asterisk, and it does not bypass passwords on accounts that have a valid password hash. Successful exploitation grants the attacker whatever permissions the compromised account already holds — which, on a default Alpine system where root is configured without a usable password, can mean full control.

A 2016 Fix That Left an Opening

Security researcher Ozgun Kultekin discovered the issue. The underlying problem traces back a decade, to a 2016 patch for CVE-2016-6210, a username enumeration flaw. In that patched code path, OpenSSH can treat a failed password-hashing operation as successful authentication, because the failure and the disabled-password state are represented the same way.

OpenSSH 10.6p2 fixes CVE-2026-123158.

What an Attacker Can Reach Next

Safe Security said unauthorized SSH access is the immediate impact, and that the broader risk depends on the privileges of the compromised account. From there, the firm said, attackers can reach deployment credentials, application secrets and connected infrastructure, enabling lateral movement or service disruption.

Because the OpenSSH SSHole flaw hands over an existing account rather than creating a new one, there is no credential theft step for defenders to spot in advance. Footholds of that kind have repeatedly been the starting point for larger incidents, from LLMjacking attacks that run up victims’ cloud bills to the social-engineering breach that Binance traced to a fake job interview.

Systems That Are Not Affected

The flaw does not affect Dropbear, glibc-based Linux distributions, non-Linux systems, or systems that check passwords through PAM. Accounts protected by strong passwords or key-based access only are not directly exposed by the bug, since the exploit depends on the asterisk password hash.

That still leaves a meaningful population of exposed machines: container images, embedded devices and lightweight cloud instances frequently run Alpine Linux, where OpenSSH is built against musl and PAM is off by default.

Patching and Hunting for Successful Logins

Affected users should install OpenSSH 10.6p2 or their distribution’s patched package and restart sshd, according to the guidance published alongside the disclosure.

Alpine also recommends checking logs for successful password logins to accounts that should not accept them. Specifically, administrators should look in /var/log/messages for sshd lines reading Accepted password for an account that has no password, such as alpine, root or any key-only user. On exposed machines, they should also review doas use and recently created users, files and authorized keys.

Alpine said that if administrators cannot rule out such a login, they should treat the machine as compromised.

Beyond patching, the recommended hardening step is to audit password-disabled accounts and remove unnecessary ones where possible, then apply the fix and restart sshd on every exposed system. With exploitation of the OpenSSH SSHole flaw observed the same day the CVE appeared, the window between disclosure and attack on this bug was measured in hours rather than weeks.

0
Show Comments (0) Hide Comments (0)
0 0 votes
Article Rating
Subscribe
Notify of
guest
0 Comments
Oldest
Newest Most Voted
0
Would love your thoughts, please comment.x
()
x