Security teams are being urged to act fast as evidence surfaces of real-world attacks exploiting a recently uncovered vulnerability in OpenSSH nicknamed “SSHole.” The flaw enables remote access to certain Linux accounts that are disabled for password login, simply by submitting a specially crafted long password—no valid credentials or SSH key needed. These findings come from the SANS Internet Storm Center’s research and related honeypot data.
Initial exploit attempts were detected on November 5, marked by password strings made up entirely of repeated “A” characters. The Cowrie SSH honeypots monitored 232 such long-password tries on that day, followed by 713 on November 6. While suspicious, these numbers represent attempts rather than confirmed break-ins or distinct attackers. Some earlier events recorded from November 1 were deemed more likely broken brute-force scripts than targeted misuse of the SSHole vulnerability.
How the Vulnerability Works
The SSHole flaw stems from a specific misconfiguration. It affects OpenSSH installations built with musl libc and when password verification is done without using PAM (the Pluggable Authentication Module system). To be vulnerable, a server needs password authentication enabled, a user account with a stored password of “*” (indicating password logins are disabled), and another local account with a valid SHA-crypt hashed password. Under those conditions, if a remote user submits a password longer than 256 bytes, musl’s crypt() function fails and returns “*”. Since SSH sees the stored “*” in the target account, it mistakenly grants access. The attack range is specifically from 257 to 1,024 bytes in length, and does not impact accounts with valid password hashes.
What’s Being Done
The issue has been addressed in OpenSSH version 10.6p2. Several Linux distributions, including Alpine, have also released patches. Administrators are strongly advised to install all relevant updates and restart the SSH daemon (sshd) as soon as possible. Where updates aren’t immediately viable, disabling password authentication is a reliable stopgap. Use of PAM for password checks also mitigates the risk. It’s important to check version banners carefully—some fix backports haven’t updated version strings, potentially misleading system operators.
For detection, review logs for unusual behavior: successful logins into accounts that should have password authentication turned off; sequences of authentication failures immediately followed by acceptance in the same session. Honeypot data already shows scanning activity for this exploit in multiple IPs. While it’s not yet confirmed how many systems have been compromised, the attack vector is live and actionable.
This vulnerability highlights the complexities of securing authentication systems—especially when dependencies like libc implementations change behavior under error conditions. As infrastructure continues to adapt with lightweight or alternate libraries like musl, engineers must rigorously test assumptions around credential handling. Organizations should ensure their SSH configurations follow hardened best practices—including disabling password authentication where possible—and monitor authentication logs vigilantly. Watch for potential expanded scans coming in the wake of this public disclosure.
