Press play to start listening
Cybercriminals are exploiting a decade old high-severity vulnerability in OpenSSH that allows them to bypass password authentication on certain Linux systems and install backdoor. The vulnerability is tracked as CVE-2026-123158 (CVSS 8.1) and is nicknamed SSHole. It affects OpenSSH running with the musl C library under specific authentication configurations.
Security researcher Özgün Kültekin discovered the issue and publicly disclosed it on November 5 when OpenSSH released a fix. The flaw dates back to a 2016 OpenSSH change addressing CVE-2016-6210, a username-enumeration vulnerability that allowed attackers to identify valid accounts by measuring authentication response times.
Understanding the issue
Linux administrators can disable password logins by placing an asterisk (*) in an account’s password field in the /etc/shadow file. However, musl’s crypt() password-hashing function also returns an asterisk when hashing fails, including when someone submits a password between 257 and 1,024 bytes long.
OpenSSH mistakenly treats this error value as a matching password hash and accepts the login. Exploitation requires SSH password authentication to be enabled, PAM (Pluggable Authentication Modules) authentication to be disabled, an account with an asterisk in its password field, and at least one other local account with a $5$ or $6$ password hash.
The flaw affects qualifying musl-based Linux systems, including Alpine Linux and potentially some OpenWrt, Buildroot and Yocto configurations. Debian and Ubuntu systems using glibc, OpenSSH installations using PAM, and OpenWrt’s default Dropbear SSH server are not affected.
Using Alpine as a container base does not, by itself, expose an application to SSHole. The container must run a reachable, vulnerable SSH server and meet the required authentication conditions.
Some older Alpine Tiny Cloud images for AWS and Azure are particularly exposed because their default alpine account has passwordless doas access, potentially allowing attackers to obtain root access if another account with a valid password hash exists.
Attackers Attempt to Install Python-Based Backdoor
OpenSSH released version 10.6p2 on November 5, 2026, to fix the vulnerability. Public proof-of-concept exploit code appeared roughly four hours later. Security firm watchTowr observed exploitation linked to botnet and cryptocurrency-mining activity on November 6.
GreyNoise detected its first successful SSHole attack on November 7 at 00:46 UTC. The activity involved 18 successful attack chains from six IP addresses targeting GreyNoise’s own vulnerable sensors.
The attackers examined running processes and containers, looked for information exposed through cloud metadata services, and tried to access password hashes and root SSH keys. They also attempted to place their own keys in authorized_keys files to retain access.
After gaining root access in one case, an attacker installed TAC Agent, a Python implant capable of running shell commands, collecting system information and transferring files. GreyNoise says its registration with the command-and-control server failed, and it never received a task. The implant contained Chinese-language comments, logs and error messages, but these do not establish who was behind the attack.
The volume of SSH activity is considerably larger than the confirmed exploitation figures. GreyNoise counted 40.7 million scans of port 22 and 30.1 million attempted SSH sessions, although it could not attribute all this traffic to SSHole.
GreyNoise grouped some of the activity under the name GT10, based on shared infrastructure, tools and actions on compromised systems. The company says other attackers are also exploiting SSHole.
Previdian separately reported 24 exploitation attempts from 15 IP addresses, and also observed activity from 11 countries across four sensors while Finnish security company Defused reported a small number of attackers testing the flaw, although it said the activity was not widespread. The US Cybersecurity and Infrastructure Security Agency (CISA) added CVE-2026-123158 to its Known Exploited Vulnerabilities (KEV) catalog on November 9.
Update and Patches Details
Though with limited scope, SSHole gives attackers a way to bypass password authentication on vulnerable systems. This makes prompt patching important. OpenSSH 10.6p2 contains the fix for SSHole.
Administrators should install that version or the patched package supplied by their Linux distribution. Alpine has released fixed packages for versions 3.16 through 3.24, including 3.21.10, 3.22.8, 3.23.8 and 3.24.4. After updating, they should restart the SSH service, as installing the package alone does not replace the running daemon.
Administrators who cannot update immediately can disable SSH password authentication by setting PasswordAuthentication no and restarting the service. They should first verify that SSH key access works.
Security Expert Warns Against Overlooking SSHole Exposure
Ramy Rahman, senior solutions engineer at ArmorCode, shared the following comments with Hackread.com, explaining why the vulnerability could affect more systems than its specific requirements suggest:
“On paper, this is a narrow bug. It only works on a particular kind of lightweight Linux setup, with password logins turned on and a specific account in place. But narrow doesn’t mean small. Alpine is a go-to base image for containers and lightweight infrastructure, so a flaw like this can be baked into hundreds of images that teams may have forgotten they’re running.”
“What makes this one fascinating is that it’s a collision of two perfectly reasonable behaviors. One C library returns an asterisk as an error. Meanwhile, accounts with no password, which is what you want for key-only users, store an asterisk to mean ‘no password.’ The error and the stored value match, and the door opens.”
“Nothing here is a classic memory-safety bug. It’s an assumption mismatch between components, and reportedly it sat there for about a decade, in part because this code is mostly tested on one OS and one C library. It’s a reminder that mainstream software can have blind spots when it runs in less-tested environments.”
“Patch to OpenSSH 10.6p2 or your distribution’s fixed package, and restart sshd, because upgrading the package doesn’t replace the running daemon. That step is easy to miss.”
“But don’t stop at patching. Look back through authentication logs for password logins to accounts that shouldn’t have passwords, and if you can’t rule out a login, treat the host as compromised.”
“Defaults matter. Password authentication is on by default in OpenSSH, so hardening that’s ‘on the list’ is real risk reduction today.”
