OpenSSH SSHole Flaw Exploited as CISA Orders Rapid Patching
OpenSSH released version 10.6p2 on November 5 to prevent the bypass. Alpine Linux, which uses musl and offers an OpenSSH server package without PAM, issued an advisory the same day. Alpine says the flaw affects systems only when password authentication is enabled, an account has an asterisk as its stored password field, and at least one other local account has a SHA-256 or SHA-512 password hash. Systems using PAM for SSH authentication or disabling password logins are outside those stated conditions.
According to Alpine, an attacker who can reach an affected SSH service can submit a password longer than 256 bytes for an account whose password field is an asterisk. The musl crypt function returns an asterisk on that error path, and the SSH server can mistake the returned value for a valid match. Alpine says the login can succeed in one connection. The vendor notes that default SSH settings prohibit password-based root login, although access through another account may still lead to elevated privileges if that account has them.
GreyNoise says its first confirmed successful exploit reached a sensor on November 7. Its November 10 report describes attackers running reconnaissance commands, probing cloud metadata services, and attempting to access password hashes and SSH keys. In one observed intrusion, an actor uploaded a Python agent and tried to establish persistence through a startup service. GreyNoise says the agent did not enroll with its command server or receive a task on the monitored system. Its sensor findings do not establish the number of production systems compromised.
Alpine says affected administrators should install the fixed OpenSSH package and restart the running sshd service; upgrading the package alone does not replace the active daemon. OpenSSH 10.6p2 contains the upstream workaround, while Alpine has issued patched packages for supported branches and several older releases. Where an update cannot be applied immediately, Alpine advises disabling SSH password authentication and restarting sshd after confirming key-based access works.
Defenders can review SSH logs for successful password logins to accounts that normally have no password, then inspect unexpected authorized keys, new users and startup services, Alpine advises. GreyNoise also publishes observed attack artifacts for incident review. Organizations should check each exposed host against the full configuration conditions before assessing exposure, and investigate suspicious successful logins on vulnerable systems.