"sshole" flaw in OpenSSH: an overly long password could unlock disabled accounts

Security researcher Ozgun Kultekin has described a vulnerability called "sshole". It affects OpenSSH combined with the musl library. According to Spider's Web, in tightly defined configurations it was possible to log in with a password to an account that should not accept any password at all. A string longer than 256 characters was enough. Kultekin says the problem in this form may have existed since 2016.

How the bug worked

On Unix-like systems, an "*" in the password field of the /etc/shadow file marks an account as locked for password login. The asterisk is not a valid password hash, so no typed password should match it.

The bug resulted from several decisions that were each reasonable on their own. In 2012, the musl developers changed how the crypt() function behaves. On failure it began returning "" instead of NULL. The same year, musl added SHA-512 crypt support with a password limit of 256 bytes. Exceeding it caused an error, which produced the result "".

In 2016, OpenSSH was fixing CVE-2016-6210, a vulnerability that allowed existing usernames to be identified from differences in server response time. The fix forced an expensive operation even for accounts without a usable password hash, including those with "". As a result, the server compared "" with "*" and let the user in.

Who is affected

This is not a universal way of breaking into any Linux machine. The attack requires several conditions at once:

• the OpenSSH server runs in a musl environment, such as Alpine Linux, OpenWrt, Buildroot or Yocto,
• PAM authentication is disabled,
• SSH password login is enabled,
• the system has an account with "*" as well as another account with a valid password hash.

In such a configuration, the account with "*" accepted strings between 257 and 1024 characters long. The flaw does not bypass a properly set password on an ordinary account. Debian, Ubuntu and Fedora, which use glibc, are not vulnerable to this mechanism. Nor are configurations that authenticate through PAM.

According to Kultekin, the official Alpine images for AWS and Azure contain the default "alpine" account affected by the problem. It is said to be able to use doas without a password, so access to it could lead to root privileges. OpenWrt, Buildroot and Yocto are commonly found in routers and embedded systems.

The role of AI in the discovery

The researcher says he used AI agents, but not in a magical way. He prepared different builds of sshd (glibc, musl, with and without PAM) and subjected them to unusual login attempts. About 17,600 tests were run, including unusual hashes, damaged accounts and very long passwords. One combination behaved differently: musl without PAM.

Fix and recommendations

The problem has been fixed in OpenSSH 10.6p2. Alpine Linux administrators are advised to update their OpenSSH packages. Where an update is not possible straight away, disabling SSH password login is suggested as a safeguard. Kultekin also points to an OpenSSH change of 30 October 2026, made after a security review. According to him, the code behind the bug sat just a few lines away.