Hackers begin exploiting OpenSSH authentication bypass

Threat actors have begun exploiting SSHole, a high-severity authentication bypass in OpenSSH that was patched last week, according to SecurityWeek. The issue, identified as CVE-2026-123158, "is related to misinterpretation of whether a string is intended to be a password hash" and could allow access to some accounts with any 257 to 1024 character password. If exploited, attackers could gain entry to accounts like root that normally reject passwords.

Last week, OpenSSH quickly released fixes, and Alpine told users to install them and restart sshd right away. Over the weekend, WatchTowr and Previdian both warned that hackers had started exploiting the flaw in the wild. According to WatchTowr, so far only botnets and cryptocurrency miners have adopted it.

Previdian said its sensors "observed 20 exploitation attempts, 13 unique attacker IPs, and 9 countries targeting CVE-2026-123158", with the first observed on Nov 06, 2026 and the last on Nov 08, 2026. GreyNoise and Defused also reported exploitation attempts.

The vulnerability impacts Linux systems using musl libc with PAM turned off, such as Alpine, Buildroot, OpenWrt, Yocto, and similar distributions. On these systems, accounts that should not accept a password, such as root, do accept one because of how sshd checks passwords. When no password hash exists for an account, as with root on Alpine where the field is '', sshd uses a salt from a different account's hash to process the login. Passwords over 256 bytes cause musl's crypt() to fail and produce '' rather than NULL, and because that equals the '*' stored for the account, sshd accepts the password.

On Alpine, the vulnerable accounts are root, key-only users made with adduser and no password, the Alpine user in the official tiny-cloud images, and users from a directory service via musl-nscd.

SecurityWeek said users should upgrade to OpenSSH 10.6p2 promptly. To reduce risk, they can turn off password authentication, which OpenSSH enables by default, or disable SSH entirely. SecurityWeek recommended that defenders examine logs for unusual requests to spot exploitation attempts.

Update, November 9, 2026

BleepingComputer reported on Monday that GreyNoise recorded the first successful SSHole exploitation in the wild on Nov. 7 at 00:46 UTC, about 40 hours after OpenSSH released the 10.6p2 fix. GreyNoise saw 16 successful exploitation chains from six source IP addresses; the attackers collected system and container details, contacted cloud metadata endpoints, sought password hashes and root SSH keys, and changed authorized_keys files to keep access. In one case, an attacker gained root and installed TAC Agent, a Python command-and-control tool, but the implant could not reach its C2 server at tac.vpnla[.]org. The agent's comments, logs, and error messages were written in Chinese, which GreyNoise said may help identify the attacker's origin. Exploitation attempts started Nov. 5, the day exploit code appeared roughly four hours after the patch, with successful exploitation the next day, according to BleepingComputer. GreyNoise also logged 27.5 million port-22 scans and 20.1 million attempted SSH sessions, though those are not confirmed SSHole attacks. Defenders should check for TAC Agent files, startup services, and SSH keys that were not authorized.