Attackers Exploit ‘SSHole’ OpenSSH Flaw to Bypass Logins

Attackers are exploiting SSHole, a high-severity authentication-bypass flaw in OpenSSH. Tracked as CVE-2026-123158, the vulnerability can let attackers access certain accounts by submitting a password between 257 and 1,024 characters long.

The flaw affects some Linux systems that use the musl standard C library and have Pluggable Authentication Module support disabled. Affected platforms include Alpine, Buildroot, OpenWrt and Yocto.

Accounts that normally should not accept passwords, including root, can be exposed in specific configurations. On Alpine, affected accounts include root, users created for key-based access without passwords, the Alpine user in official tiny-cloud images and some directory-service users connected through musl-nscd.

The problem occurs when OpenSSH checks a submitted password against the stored password record for an account. If the account has no password hash and its record contains an asterisk, the SSH server can use a salt from another account while processing the login attempt.

For passwords longer than 256 bytes, musl’s crypt() function returns an asterisk instead of a null result. OpenSSH can interpret that returned value as matching the asterisk in the target account’s record and approve the login.

Successful exploitation could provide access to root or another account configured to accept key-based access only. The vulnerability does not affect every Linux system and requires the affected musl and PAM configuration.

OpenSSH developers released patches last week, and Alpine advised users to apply them and restart the SSH service. The fix is included in OpenSSH 10.6p2.

Researchers observed exploitation attempts from Nov. 6 through Nov. 8, 2026. The activity has so far been linked to botnets and cryptocurrency-mining operations. Monitoring groups have also reported scanning and attempted exploitation.

One monitoring service recorded 20 attempts from 13 unique IP addresses in nine countries. The first attempt was observed Nov. 6, and the most recent was recorded Nov. 8.

Administrators who cannot update immediately can disable password authentication or shut down SSH access. They should review SSH logs for unusually long password attempts and other signs of unauthorized access.