If your team uses SSH keys to manage a Linux server, you’d expect an account with no password to reject every password login. On some OpenSSH servers, a flaw called SSHole breaks that assumption. An attacker who can reach the SSH service and knows the name of an eligible account can sign in without a valid password or the account’s SSH key.
OpenSSH released its fix on November 5, 2026. Four days later, the Cybersecurity and Infrastructure Security Agency (CISA) added CVE-2026-123158 to its Known Exploited Vulnerabilities Catalog. If an affected server was reachable from the internet, prioritize both patching it and reviewing its authentication logs.
Which OpenSSH servers are affected?
SSHole affects certain Linux systems running the OpenSSH server with the musl C library, PAM disabled, and SSH password authentication enabled. On affected Alpine Linux systems, the target account has an asterisk in its stored password field, and at least one other local account has a SHA-256 or SHA-512 crypt password hash. When an attacker submits an unusually long password, musl’s password-hashing function can return an asterisk to signal an error. The vulnerable SSH login process can mistake that error for a match.
Alpine’s default OpenSSH setting blocks direct root password logins. Check whether your team changed that setting and whether any affected account can elevate to root after logging in. Start with internet-facing SSH servers, including cloud instances and remote administration hosts. Ask your IT provider about appliances with embedded Linux and check whether any Alpine-based containers actually run the SSH server. That detail can save time if Alpine appears throughout your container inventory.
How to patch or mitigate SSHole
Portable OpenSSH 10.6p2 contains the upstream fix. Install the fixed package or firmware for your operating system or device, and verify it against the vendor’s advisory. Alpine backported the fix to earlier OpenSSH versions, so the upstream version number alone can give you the wrong answer. On Alpine, restart the SSH service after updating because the package upgrade leaves the existing daemon running. Confirm that a fresh administrative session works before you close your current one.
If you need time to patch, Alpine recommends setting PasswordAuthentication no and restarting sshd. Test SSH key access before making the change, keep your current session open, and verify that the effective setting applies to the accounts you intended to protect. For services that only administrators need to reach, restrict access to approved networks or a VPN while the update is pending.
What to look for in your SSH logs
On previously exposed Alpine systems, look for successful password logins to accounts with no password set. Alpine specifically calls out log entries containing Accepted password for followed by a key-only account name. Review unexpected privilege elevation, newly created accounts, and changes to authorized SSH keys. If you find an unexplained successful login, preserve the logs, isolate the affected system, and start your incident response process.
If you rely on an IT provider, ask for the affected hosts, the vendor-fixed package or firmware installed on each, and the results of the log review. Knowing which systems were reachable and whether anyone got in helps you protect the applications and data those accounts could access.
