Hackers Target OpenSSH SSHole Flaw Within Hours of Disclosure, Gain Root on Honeypot

SSHole is a high-severity OpenSSH flaw that can grant unauthorized access without stolen credentials or SSH keys. It affects certain Linux systems using the musl C library, with PAM disabled. The risk is greatest for accounts intentionally configured without usable passwords.

An attacker sends an arbitrary password between 257 and 1,024 bytes long. That causes password hashing to fail. OpenSSH then produces an asterisk, the same value used for password-disabled accounts. The daemon compares that asterisk with the account’s stored password field and accepts the login.

The attack does not bypass valid password hashes. It requires an account whose stored password value is an asterisk. OpenSSH 10.6p2 fixes the issue. Administrators should install the patched version or their distribution’s update, restart sshd, and investigate suspicious accepted-password log entries.

Previdian observed the first SSHole exploitation attempt less than nine hours after the CVE was published. That rapid timing shows how quickly attackers began testing exposed systems after the vulnerability became public.

Telemetry recorded eight exploitation attempts in total. They came from an IP address geolocated to Japan. The observed source address was 89.116.89.18. Attackers used oversized passwords and ran reconnaissance commands through non-interactive SSH sessions.

Previdian also confirmed successful root access on a honeypot running Alpine Linux and OpenSSH. The observed commands included id, uname, and hostname. These findings show that exploitation was not merely theoretical. Exposed systems should be patched and reviewed for suspicious login records, account activity, files, and authorized keys.

SSHole affects Linux systems running OpenSSH on the musl C library when Pluggable Authentication Modules, or PAM, are disabled. Alpine Linux is specifically exposed because its default OpenSSH server configuration fits those conditions.

The vulnerable setup matters because OpenSSH handles password verification directly in this configuration. An attacker can send an oversized password, trigger a failed hashing operation, and potentially log into an account whose stored password value is an asterisk. Valid password-hash accounts are not bypassed.

The article identifies several unaffected cases. Dropbear is not affected. Neither are glibc-based Linux distributions or non-Linux systems. Systems that check passwords through PAM are also excluded. Administrators should confirm both their operating system’s C library and their SSH authentication configuration before assessing exposure.

The password length is important because the article says inputs from 257 to 1,024 bytes cause the password-hashing operation to fail under the affected conditions. The attacker does not need to know the account’s real password. The failure itself creates the dangerous result.

When hashing fails, OpenSSH mistakenly produces the value “*”. That value is also used to indicate an account with its password disabled at the system level. The sshd daemon then compares the returned asterisk with the asterisk stored in the account’s password field. The comparison succeeds, so authentication is granted.

This behavior only helps against accounts configured with an asterisk password value. It does not bypass accounts containing valid password hashes. The defect was fixed in OpenSSH 10.6p2, so updating and restarting sshd removes the vulnerable behavior.

SSHole’s immediate consequence is unauthorized SSH access to a password-disabled account. The attacker receives the permissions already assigned to that account. Safe Security said the impact therefore depends on the compromised account’s privileges.

A low-privilege account may provide limited access, while a highly privileged account can expose much more of the system. Previdian confirmed successful root access on an Alpine Linux honeypot, demonstrating that exploitation can reach the highest-privilege account when it is configured in the vulnerable way.

Attackers may also obtain deployment credentials, application secrets, and access to connected infrastructure. Those resources could support lateral movement or service disruption. Alpine recommends reviewing doas use, recently created users, files, and authorized keys. If administrators cannot rule out a login, they should treat the machine as compromised.

The vulnerability traces back to a patch introduced in 2016. That patch addressed CVE-2016-6210, a username enumeration vulnerability. The later SSHole flaw emerged from how the patched code handled password processing under particular conditions.

OpenSSH could interpret a failed password-hashing operation as successful authentication. The failed operation produced “*”, which was also the marker used for an account whose password was disabled at the system level. When sshd compared that result with the stored asterisk, it treated the values as matching.

An attacker could trigger the behavior with an arbitrary password between 257 and 1,024 bytes long. The flaw remained limited to accounts storing an asterisk and affected configurations without PAM on musl-based Linux. OpenSSH 10.6p2 addresses the issue, ending the defective authentication path for patched systems.

SSH is the protocol used for secure remote access to systems. OpenSSH is the software implementation involved here, including the sshd server that accepts login attempts. A user normally authenticates with a password or an SSH key, depending on the server’s settings.

PAM, or Pluggable Authentication Modules, is a system for checking authentication through configurable modules. The article distinguishes systems that use PAM from affected systems where PAM is disabled. A password hash is a transformed value stored for comparison, rather than the usable password itself.

Normally, the submitted password is processed and checked against the account’s stored password value. In the SSHole scenario, a failed hashing operation incorrectly returned “*”. Because “*” also represented a disabled password, sshd accepted the comparison. That normal separation failed only under the article’s specified conditions.