CVE-2026-123158: *sshole Bypass in musl-based Linux SSH

A significant authentication bypass vulnerability, dubbed “*sshole” and assigned CVE-2026-123158, has been identified in lightweight Linux distributions built on musl libc. This flaw allows an attacker to log into passwordless accounts via OpenSSH by supplying a specific long password, potentially leading to unauthorized system access and server takeover. Distributions like Alpine Linux, widely used for Docker containers and cloud servers, are particularly affected by this issue, which has been rated 8.1 out of 10 under CVSS 3.1.

Understanding the OpenSSH Password Bypass in musl libc

The *sshole vulnerability exploits a logical flaw in how the musl C library’s hashing function interacts with OpenSSH when processing unusually long passwords. Security researcher Özgün Kültekin discovered that if a password between 257 and 1024 characters is entered for an account designed to be passwordless, the musl hashing function encounters an error and returns an asterisk (*) as its output. Since passwordless accounts store a single asterisk where a password hash would normally reside, the OpenSSH server (sshd) compares the two asterisks and treats the input as a valid password, granting access.

This bypass specifically occurs when the sshd daemon is not configured to use Pluggable Authentication Modules (PAM), which is the default setting for Alpine Linux’s standard OpenSSH package. For an attacker to exploit this, they need to know the name of a passwordless account, and the target machine must also have at least one other account configured with a real password. The vulnerability’s development traces back to 2016, ironically introduced by a fix for CVE-2016-6210, a timing flaw that allowed attackers to enumerate usernames using long passwords.

Affected Environments and Impact

Alpine Linux is the primary distribution identified as vulnerable, particularly its cloud images. While the root account has been passwordless on Alpine since version 3.16, OpenSSH’s default settings typically refuse password logins for root. However, Alpine’s official cloud images often feature a default alpine user that is passwordless and can escalate privileges to root without a password. On such systems, an attacker can log in as the alpine user using the *sshole bypass and subsequently compromise the server, as long as any other account on the machine has a password.

Alpine containers are only at risk if they are running sshd, which is not a common default configuration. Other systems built with frameworks like Buildroot or Yocto, or OpenWrt devices that have replaced the default Dropbear SSH server with OpenSSH, may also be susceptible. According to itnews.com.au, the original discovery was aided by AI agent swarms, testing various OpenSSH, glibc, musl, and PAM configurations against thousands of unusual login attempts.

Mitigating *sshole Vulnerability in Lightweight Linux

Defenders must take immediate action to protect systems from this authentication bypass. Addressing the *sshole vulnerability requires either a configuration change or applying available patches.

Alpine Linux CVE-2026-123158 Patch Guidance and Recommendations

The most straightforward mitigation is to disable password authentication for SSH where it is not strictly necessary. As recommended by OpenSSH developer Damien Miller:

• Disable Password Authentication: Set PasswordAuthentication=no in your sshd_config file. This immediately closes the vulnerability by preventing password-based logins altogether.

For those requiring password authentication, official patches are available:

• OpenSSH Update: Upgrade to OpenSSH version 10.6p2. After updating, administrators must restart the sshd service for the changes to take effect.
• Alpine Linux Patches: Alpine Linux has released patched packages for all active branches, extending back to version 3.16. System administrators should update their Alpine Linux installations to the latest patched versions to apply the fix.

Regular auditing of sshd_config files and ensuring that sshd is not running on containers unless absolutely essential are also good security practices. This vulnerability underscores the importance of carefully managing authentication methods, especially in lightweight and cloud-native environments.

Related: OpenSSH Auth Bypass on Alpine Linux via Long Passwords