Security researcher discloses OpenSSH sshole authentication bypass on Alpine Linux

Security researcher Özgün Kültekin of Wakefield disclosed an OpenSSH authentication bypass nicknamed sshole on Nov. 5, 2026 that lets attackers enter Alpine Linux and other musl-based accounts blocking password logins through an oversized password.

The flaw reaches OpenSSH servers running on musl-based Linux distributions such as Alpine Linux, OpenWrt, Buildroot, and Yocto. Systems using glibc, such as Debian, Ubuntu, and Fedora, are not vulnerable, and neither are Linux machines authenticating through PAM or machines running non-Linux operating systems.

A system is exposed when it runs OpenSSH on musl Linux with PAM turned off and password authentication still on, and when it holds one account marked with * in its password field and a second account that stores a real hash. One passworded account opens up every account that lacks a password.

An attacker must know a password-free account’s name, have network access to the server, and supply a password from 257 to 1,024 bytes long. When password hashing fails in musl, such as with a password longer than 256 bytes, crypt() gives back an asterisk, and sshd accepts the login because the stored asterisk matches the returned marker. A password of 300 repeated characters can bypass authentication on vulnerable systems.

When sshd checks an account whose password field holds only an asterisk, it pulls the salt from a different account that stores a real hash. The weakness dates back to 2016 and originates in how OpenSSH handles password verification problems on musl systems. An OpenSSH change from 2016 tied to CVE-2016-6210 made sshd run password hashing for accounts lacking usable password hashes, including ones marked with *. It is not like earlier OpenSSH client and server flaws that involved interception and service disruption.

On August 9, 2012, musl altered failed crypt() behavior to send back an unmatchable hash instead of NULL. On August 29, 2012, musl set a 256-byte password limit to protect servers from denial-of-service attacks.

On Alpine, password-free accounts include key-only users, directory users through musl-nscd, root, and the alpine user from official tiny-cloud images. Official Alpine tiny-cloud images from 3.18.11 through 3.24.3 give the alpine user passwordless doas privileges, so an intruder signed in as alpine can run passwordless doas to reach root. The images start safe at first boot but turn exploitable once a password hash is added to any account, and setting a password on one account can expose other accounts built without passwords.

The Alpine base image has shipped root as root:* since about version 3.16, and PermitRootLogin prohibit-password protects root by default, with direct root login available only when PermitRootLogin yes is configured. On OpenWrt, Dropbear is the default SSH handler and is not affected; the issue applies only when an administrator installs the OpenSSH server.

Not affected are containers with no SSH server running, systems where PasswordAuthentication is set to no, cloud-init images, locked accounts carrying! in /etc/shadow, and machines lacking a dollar-style password hash. The bypass does not work on accounts holding valid password hashes.

All Alpine releases from 3.16 through 3.24, plus edge, are exposed. Alpine published fixed openssh-server packages covering every release back to 3.16, and branches 3.16 to 3.21 that are past end of support received fixed packages as well. The fixed point releases are 3.21.10, 3.22.8, 3.23.8, and 3.24.4. Version 3.16 came out in May 2022.

OpenSSH calls the flaw critical and released Portable 10.6p2 on Nov. 5, 2026 to block it. The flaw had no CVE identifier assigned as of Nov. 5, 2026. Alpine administrators should update OpenSSH packages by running apk upgrade openssh, and the admin must restart sshd with rc-service sshd restart once the package is updated because upgrading leaves the running sshd in place. On Alpine 3.19 and later, the default configuration reads drop-in files located in /etc/ssh/sshd_config.d.

The 10.6p2 workaround causes sshd to reject a match if the stored password field has fewer than four characters. OpenSSH calls the 10.6p2 change a workaround and says the root cause lies outside sshd. Damien Miller of OpenSSH said his team heard about the flaw earlier in the week and pushed out the fix quickly. He said long embargoes are risky mainly because AI agents can locate the same flaws within hours. “set PasswordAuthentication=no or disable SSH for these systems IMMEDIATELY.”

Teams that cannot patch right away can stop the attack by switching PasswordAuthentication to no in the SSH server configuration and then restart sshd. Before turning off password authentication, administrators should confirm that SSH key login works and keep the session open until another login works. Detectify advises keeping SSH off the open internet where possible.

As of Nov. 5, 2026, no attacks using the flaw had been reported. Detectify said that as of Nov. 5 at 15.30h CET it had seen no public reports of someone exploiting it and expected scanning attempts since the information is public and the attack is straightforward to carry out. Alpine’s advisory states that the attack succeeds every time over a single connection when the required conditions exist. Alpine’s Nov. 5, 2026 security advisory covers an authentication bypass in the openssh-server package nicknamed sshole.

Administrators can hunt for signs of exploitation in /var/log/messages by looking for Accepted password entries linked to accounts that should not allow password logins. The command grep “Accepted password” /var/log/messages shows successful SSH password logins on Alpine, while grep ‘^alpine:’ /etc/shadow reveals whether the alpine account’s password field is *. If the logs show a password login that succeeded for an account whose field holds *, and the login cannot be ruled out, treat the machine as compromised. On exposed machines, the team should also review doas usage, new accounts, new files, and new authorized keys.

Kültekin used AI agents to run about 17,600 authentication tests against assorted OpenSSH setups, malformed password hashes, and oversized passwords to find the vulnerability. Özgün Kültekin of Wakefield published research on sshhole.com explaining that an unusually long password turns a failed password check into access.