OpenSSH Flaw Lets Hackers Into Linux Servers Without a Password

A newly disclosed OpenSSH vulnerability could let attackers enter certain Linux servers without knowing an account’s password. The first reported attack attempts appeared less than nine hours after the flaw became public, and a security researcher says an attacker successfully gained root access to a test server.

The vulnerability, tracked as CVE-2026-123158 and nicknamed “sshole”, affects specific OpenSSH configurations that use the musl C library without PAM authentication. It does not affect every Linux system, but the possibility of bypassing passwords makes it an urgent issue for administrators running vulnerable servers.

Ryan Dewhurst, founder of security firm Previdian, told Help Net Security that the company’s first observed attack attempt arrived less than nine hours after the vulnerability was published. He also reported successful root access on a Previdian honeypot running Alpine Linux and OpenSSH.

The activity was limited in the evidence reported so far. Previdian counted eight attempts, all coming from a single Japan-based IP address and detected by one sensor. This confirms that someone was testing the vulnerability, but it does not establish a widespread campaign or show how many real servers have been compromised.

What makes the flaw particularly concerning is that it can affect accounts designed not to accept password logins. These accounts are often used for SSH key-based access, where users authenticate with a private key rather than a password.

The problem involves OpenSSH and musl, a lightweight C library used by Alpine Linux and other Linux-based systems. It can occur when OpenSSH is built and run without Pluggable Authentication Modules (PAM), a system commonly used to handle authentication.

On an affected server, an attacker who can reach the SSH service and knows the name of a suitable account may be able to log in by submitting an unusually long password between 257 and 1,024 bytes. The password itself does not need to be correct.

This happens because of an unexpected interaction between OpenSSH and musl. When musl’s crypt() function receives a password that is too long, it can return an asterisk (*) to indicate an error. However, an asterisk is also used in the system’s password file for accounts that do not have a usable password hash.

Under the affected conditions, OpenSSH can mistake the error response for a matching password hash. An authentication check that should reject the login can therefore allow it.

Alpine Linux’s security advisory explains that the attack requires several conditions to be present. The server must use the standard openssh-server package built without PAM, or the PAM-enabled package with UsePAM no. Password authentication must also be enabled. In addition, the attacker needs the name of an account whose password field contains *, and the machine must have at least one other local account with a $5$ or $6$ password hash.

Alpine’s standard OpenSSH server package is built without PAM, making the issue particularly relevant to administrators using that package. The project identified affected configurations across Alpine releases from 3.16 through 3.24, as well as its edge branch.

Some official Alpine tiny-cloud images also need attention. Images from versions 3.18.11 through 3.24.3 include an alpine account with a * password field and passwordless doas, a tool that allows administrative commands. These images are safe on first boot, but can become vulnerable when a suitable password hash is added to the system. An attacker who gains access to the alpine account may then be able to use doas to become root.

This does not mean every Alpine cloud image is exposed. Images configured through cloud-init with password authentication disabled are among the configurations Alpine identifies as not affected. Administrators should check how their systems were built and configured rather than assume that every installation is vulnerable.

The risk may also extend beyond Alpine. Other systems using musl and OpenSSH with the same authentication conditions may need investigation. OpenWrt, Buildroot and Yocto are among the platforms researchers have identified as worth checking, but their exposure depends on their individual builds and configurations. Systems using Dropbear instead of OpenSSH are not affected by this particular OpenSSH flaw.

The vulnerability carries a CVSS v3.1 score of 8.1, rated High. This is the standard score associated with CVE-2026-123158, not a Critical 9.8 rating. Some vendors may publish their own platform-specific severity scores, which should not be confused with the CVE’s standard score.

The underlying problem is believed to trace back to an OpenSSH change introduced in 2016. That change was intended to make authentication responses less useful to attackers trying to discover whether a username exists on a server. The newly identified issue shows how that protection could interact unexpectedly with musl’s handling of unusually long passwords.

OpenSSH released version 10.6p2 on November 5, 2026, to prevent the authentication bypass. Its release notes describe the change as a critical security workaround for certain Linux systems using musl without PAM. The OpenSSH team says the root cause is outside sshd, but that the issue can be exploited through the SSH server and prevented there.

OpenSSH developer Damien Miller also urged administrators using musl without PAM to disable password authentication or turn off SSH if they could not install the fix immediately.

Alpine has released fixed packages for affected branches, including older releases going back to version 3.16. Administrators should install the correct package for their Alpine release and restart the SSH service afterwards. This last step is important because upgrading the package alone does not replace an SSH daemon that is already running.

If an update cannot be installed immediately, Alpine recommends setting PasswordAuthentication no in the SSH server configuration and restarting the service. Before making this change, administrators should confirm that SSH key-based access works and keep their current session open while testing a new connection. Otherwise, they could accidentally lock themselves out.

Administrators should also check authentication logs for unexpected successful password logins involving accounts that should not accept passwords, such as alpine or key-only users. Alpine recommends reviewing doas activity, recently created accounts, changed files and unfamiliar SSH authorised keys. If an unauthorised login cannot be ruled out, the system should be treated as compromised.

For people using everyday Linux distributions, this is not a reason to assume their computers have been exposed. The vulnerability depends on a specific combination of software and authentication settings. Red Hat has confirmed that its products are not affected because they use glibc and PAM by default. Standard Debian and Ubuntu installations also use glibc and are outside the configuration described in this advisory.

The immediate concern is for organisations and administrators running internet-accessible Alpine servers, cloud images, appliances or other systems that combine musl with OpenSSH. The attack method is straightforward once the required conditions are present, and the first reported attempts appeared within hours of disclosure.

Administrators should check whether their systems meet the affected conditions, install the appropriate security update, restart the SSH service and investigate any unexpected successful password logins. A server account designed to reject password authentication should never become accessible simply because someone submits a longer password.