SSHole: Long passwords bypass authentication on affected OpenSSH systems

A newly disclosed vulnerability dubbed *sshole allows attackers to access certain Linux accounts without knowing a valid password, simply by submitting an arbitrary password between 257 and 1,024 bytes long. OpenSSH released 10.6p2 on 5 November 2026 to block the authentication bypass, describing the update as a critical security workaround.

Discovered by Özgün Kültekin of Wakefield, the flaw affects a specific combination of OpenSSH and musl libc, the C library used by Alpine Linux and some embedded Linux builds. OpenSSH’s developers say the underlying cause lies outside the SSH server itself, although it can be exploited through it.

Exposure depends on several conditions occurring together: OpenSSH must run without PAM authentication, password logins must remain enabled, and the targeted account must have a single * in its password field. Another local account must also have a SHA-256 or SHA-512 password hash. Certain OpenWrt, Buildroot and Yocto configurations can therefore be affected, but those platforms are not universally vulnerable.

The bypass stems from an unfortunate collision between error handling and account configuration. A * password field normally prevents password-based access. However, musl’s hashing function can return that same character when it rejects an oversized password. In the vulnerable authentication path, OpenSSH compares the error value with the stored field, finds a match and accepts the login.

The consequences can extend to full administrative control. Wakefield demonstrated that affected Alpine cloud configurations expose the default alpine account, which can use passwordless doas to become root. This requires the other exposure conditions to be present; merely deploying an Alpine image does not automatically make it exploitable. Systems using glibc, OpenSSH authentication through PAM, or the Dropbear SSH server are not affected by this flaw.

Administrators should install OpenSSH 10.6p2 or a distribution package containing the fix. Where immediate patching is impossible, disabling SSH password authentication with PasswordAuthentication no and restarting the service provides a mitigation. Working SSH-key access should be confirmed before making that change.

• Researcher’s original disclosure: sshhole.com
• Detailed security advisory: Wakefield, OpenSSH Password Authentication Bypass