OpenSSH Password Authentication Bypass on musl Linux

Research and disclosure: Özgün Kültekin, Wakefield · November 5, 2026

Summary

Wakefield found a flaw that let an attacker log in to an OpenSSH account with no password set, by sending any password between 257 and 1,024 characters long.
It affects OpenSSH on Linux systems built on the musl C library, such as Alpine, when OpenSSH runs without PAM and password login is on. Both are the default on Alpine.
On Alpine's official AWS and Azure images, the default user is one of these accounts and can run commands as root without a password. These servers are exposed once any other account has a password set.
The flaw has been exploitable since OpenSSH 7.3p1, released in 2016.
OpenSSH 10.6p2, released on November 5, 2026, fixes it. Patched Alpine packages were released the same day.

Overview

Some accounts have no password by design. Their password field holds a single *, which no password can match. Root on Alpine, users who sign in with SSH keys only and LDAP users are examples. These accounts should never accept a password.

On affected servers, they accepted any password between 257 and 1,024 characters long.

The OpenSSH release notes describe 10.6p2 as "a critical security workaround that affects Linux systems that use the musl libc and PAM disabled." The OpenSSH team considers the root cause to be outside OpenSSH, and fixed it in OpenSSH because it can be exploited there.

The full technical write-up, with the history behind the flaw, is at sshhole.com.

Impact

An attacker who can reach the SSH port can log in as an account with no password set.

On Alpine's official AWS and Azure images, the default alpine user is such an account, and it can run commands as root through doas without a password. On those servers, the flaw leads to root access.

On Alpine, root also has no password set. If PermitRootLogin yes is set, an attacker can log in as root directly.

Who is affected

A server is affected only when all of these are true:

It runs on musl libc. Examples include Alpine, OpenWrt, postmarketOS, Void (musl), Chimera, and Buildroot and Yocto builds that use musl.
OpenSSH runs without PAM. Alpine's standard openssh-server package is built without PAM. The openssh-server-pam package with UsePAM yes is not affected.
SSH password login is on. This is the OpenSSH default.
At least one account has exactly * as its password field.
At least one other account has a real SHA-256 or SHA-512 password hash, for example because someone ran passwd.

Debian, Ubuntu, Fedora and other glibc-based systems are not affected. Also not affected: OpenSSH with PAM, the Dropbear SSH server, OpenBSD, FreeBSD and macOS.

A check script at github.com/oz9un/sshole tells you if a server is exposed and which accounts are at risk.

What to do

Update OpenSSH to 10.6p2, or to a distribution package that includes the fix. On Alpine, run apk upgrade openssh.

If you cannot update right away, set PasswordAuthentication no in the SSH server configuration and restart it. This closes the flaw completely.

Checking for past use

An account whose password field is * should never log in with a password. An "Accepted password" entry in your SSH logs for one of these accounts is a strong sign the flaw was used. Investigate that server as compromised.

Common questions

Is there a fix for older OpenSSH versions?

Yes. The upstream patch applies to every release from 7.3p1 onward. It is included unchanged in the sshole repository.

How did this happen?

The flaw comes from three changes in three projects, made years apart. Each one fixed a different problem. In 2012, musl changed how its password hashing reports errors and capped password length to prevent denial of service. In 2016, OpenSSH changed how it checks passwords for some accounts to stop a timing leak. In 2022, Alpine changed root's password field so SSH key logins would work again.

How we found it

The password check is where OpenSSH meets the C library. We built OpenSSH in every configuration we could set up: glibc and musl, with and without PAM, with and without shadow passwords. Our agents then ran about 17,600 unusual login attempts across these builds, with malformed hashes, locked accounts and oversized passwords.

Every build gave the same answer for every attempt except one. OpenSSH on musl without PAM accepted logins that the others rejected.

The proof of concept reproduces the flaw on Alpine 3.24 with the standard openssh-server package and default configuration. It also works on Alpine releases back to at least 3.18, and on OpenSSH 7.5p1 from 2017.

How Wakefield can help

Wakefield helps enterprises continuously find and fix critical vulnerabilities, with or without source code. Agents test your applications the way an attacker would. A separate agent replays each finding before it reaches you, and findings it cannot reproduce never reach your list. Wakefield then helps patch the root cause and retests the fix.

Disclosure timeline

We reported this flaw privately and published after the fix was released.

November 3, 2026. Wakefield finds the flaw and reports it to the OpenSSH security team. The OpenSSH team sends a patch in under an hour.
November 4, 2026. Alpine and musl maintainers are notified.
November 5, 2026. OpenSSH 10.6p2 and patched Alpine packages are released. Public disclosure.

We thank the OpenSSH and Alpine teams for their quick response.

Contact

Questions about this research: contact@wakefield.co. To see Wakefield on your own applications, book a demo at wakefield.co/demo.