A newly disclosed authentication bypass known as the SSHhole bug allows attackers to gain access to systems running Alpine Linux and certain other distributions by simply entering a password longer than 256 characters. The flaw arises from a combination of issues in OpenSSH and musl libc, and it affects configurations where password authentication is enabled and an empty password is set for a user—a default on several distributions.
How the Bypass Works
The vulnerability chain begins with musl’s crypt() function, which returns an asterisk (*) as an error condition rather than a null value as is customary. OpenSSH then treats that asterisk as a password hash and proceeds with a comparison it should not perform. When an overly long input is supplied, the sequence of mistakes results in a successful login without the correct password.
The required conditions are specific: OpenSSH must be in use, musl must be the C library, password authentication must not be explicitly disabled, PAM must not be in use, and at least one arbitrary user must have a password set using a SHA-512/256 hash. When these conditions align, an attacker can type any string exceeding 256 characters at the password prompt and be granted access.
Which Systems Are at Risk
Alpine Linux stands out as the most significant concern. It is widely deployed in Docker and Kubernetes containers, Proxmox environments, cloud virtual machines, servers, and embedded devices, with potentially millions of installations. Alpine ships with the necessary conditions set and password authentication enabled by default, making immediate patching critical.
Other distributions are also affected. Buildroot, Yocto, and Void Linux contain the bug, though it may not be enabled by default. OpenWRT uses Dropbear for authentication by default, but users who install OpenSSH instead become vulnerable.
Mitigation and Patching
Both OpenSSH and musl have published fixes and advisories. OpenSSH released a patch and an advisory post, and musl author Rich Felker published a separate advisory. Each project appears to attribute fault to the other, though from an external perspective, responsibility is shared.
For systems that cannot be patched immediately, the simplest mitigation is to explicitly set PasswordAuthentication to no in the OpenSSH configuration file and restart the service. This disables password-based logins entirely, closing the attack vector.
Exposure and Practical Risk
While the majority of Alpine and similar installations are not directly reachable from the internet, the threat is far from negligible. Any attacker with access to an internal network—whether corporate, home lab, cloud network, or VPN—can exploit the flaw to let themselves in. In large corporate environments, obtaining a single valid user account is often not difficult, and once inside, an attacker can move laterally.
Scanning for and testing the vulnerability is trivial, lowering the barrier for exploitation. The SSHhole website provides full details on the flaw and the conditions under which it can be triggered.
Administrators of Alpine Linux and other affected distributions should apply patches without delay and review their OpenSSH configurations to ensure password authentication is disabled where it is not explicitly required.
