SSHole. Can this star be trusted? Or CVE-2026–123158

In early November 2026, a critical vulnerability dubbed “SSHole” was discovered in OpenSSH and promptly patched. It allows a remote attacker to bypass authentication and gain access to a system — including with root privileges — without needing a password. Due to the ease of exploitation and the emergence of public exploits, attacks began within hours of the vulnerability being disclosed.
**
The problem arises due to the unexpected interaction of three factors**

1. Special accounts: in Linux, there are accounts that are not allowed to log in with a password. In the /etc/shadow file, the password field contains the * symbol.
2. Error in musl: The crypt() function in musl fails when receiving a password longer than 256 bytes for SHA-256/512 hashes and returns the * symbol instead of the expected error value.
3. Logical collision: When an attacker sends a password between 257 and 1024 bytes long, OpenSSH hashes it, receives * in response, and compares it with the * symbol stored in /etc/shadow for a passwordless account. The system mistakenly interprets this as successful authentication.

The vulnerability has been assigned a high CVSS severity rating of 8.1 (High)

Ease of exploitation: A single SSH connection with the transmission of a password within the specified length range is sufficient for an attack. The attacker only needs to know the account name, which is easy to guess on standard images.

Rapid attacks: the first instance of exploitation was recorded less than nine hours after the information was published. During the attack on the honeypot, the attacker was able to gain access with root privileges. The attacks were carried out from IP addresses in different countries, which indicates broad interest from attackers.

Consequences: In real attacks, after gaining access, attackers conducted system reconnaissance, attempted to read password hashes and SSH keys, and modified authorized_keys files to establish persistence in the system. In one case, a malicious Python agent was installed for remote control (C2).

What you need to do to protect yourself

Update OpenSSH: The most important step is to update OpenSSH to version 10.6p2 or higher. For Alpine Linux, updated packages are also available for supported branches.

Check the logs: Analyze the logs for successful password logins to accounts that should only use keys, as well as for unusually long passwords in authentication requests.

Temporary measures: If updating is not possible, disable password authentication by setting the PasswordAuthentication parameter to no in the sshd configuration and restarting the service. You can also restrict access to the SSH port using a firewall.
That’s all!

I hope you found the material in my article useful and interesting. Good luck, and stay safe online!