SSH is one of the most trusted mechanisms for remotely administering Linux systems. But a newly disclosed vulnerability demonstrates how an unexpected behaviour in an underlying system library can undermine that trust.
Tracked as CVE-2026-123158, and nicknamed SSHole, the vulnerability allows attackers to bypass password authentication on certain Linux systems running OpenSSH with musl libc and without PAM authentication.
With a CVSS 3.1 score of 8.1 (High), this is particularly relevant to Alpine Linux deployments and other environments using similar configurations.
How the vulnerability works
The issue lies in the interaction between OpenSSH and musl libc’s crypt() function.
During password authentication, OpenSSH uses the system’s password-hashing implementation to validate the supplied credentials.
However, musl libc handles excessively long password inputs differently. When the supplied password exceeds its supported length, crypt() can return an asterisk (*) instead of a valid password hash.
This becomes dangerous under specific account configurations.
An attacker can submit a password between 257 and 1,024 characters. Under the vulnerable conditions, the returned asterisk can match the stored password field of an account configured without a valid password.
OpenSSH incorrectly interprets this comparison as successful authentication.
In effect, an account intended to reject password-based access can become accessible without its legitimate credentials.
Who is affected?
The vulnerability is configuration-dependent. The primary exposure conditions are:
- OpenSSH server running against musl libc.
- PAM authentication disabled.
- Password authentication enabled.
- A target account with
*in its password field. - Another local account with a supported password hash, providing the conditions for the vulnerable password-hashing path.
Alpine Linux is a prominent affected environment. Other musl-based deployments, including OpenWrt, Buildroot and Yocto, should also be assessed.
Systems using glibc or PAM-based authentication are not affected by this specific vulnerability path.
Remediation
OpenSSH released version 10.6p2 on November 5, 2026, addressing the authentication bypass.
Alpine Linux has also published fixes across its distribution branches. Administrators should apply the appropriate vendor package update rather than relying solely on upstream version comparisons.
Where immediate patching is not possible:
- Disable SSH password authentication.
- Restrict SSH access to trusted network sources.
- Review accounts configured for key-only access.
- Restart the SSH daemon after applying updates.
- Investigate unexpected successful SSH logins.
What security teams should prioritise
The immediate priority is identifying OpenSSH deployments running on musl-based Linux systems.
Asset discovery should cover cloud instances, containers, network appliances and embedded Linux environments. Validate the libc implementation, PAM configuration and SSH authentication settings before determining exposure.
Public PoC material is available, and exploitation attempts have been reported. This makes timely exposure validation and patching important.
The takeaway
SSHole is a reminder that authentication security does not depend on the protocol alone. It also depends on the libraries, operating system interfaces and error-handling mechanisms beneath it.
A single unexpected return value can turn an authentication failure into an authentication bypass.
Sometimes, the biggest security failure is not an incorrect password. It is a system that mistakenly believes the password was correct.
