OpenSSH Password Authentication Bypass on Alpine Linux (*sshole) – CVE-2026

A decade-old vulnerability in OpenSSH allows attackers to bypass password authentication on vulnerable Alpine Linux systems simply by entering an unusually long password. Tracked as CVE-2026-123158, the flaw can grant unauthorized access to accounts configured to reject password logins, potentially leading to root-level access on affected cloud systems. OpenSSH and Alpine Linux released fixes on November 5, 2026.

On November 5, 2026, OpenSSH released version 10.6p2 to address a password authentication bypass affecting Linux systems that use musl libc without Pluggable Authentication Modules (PAM), including Alpine Linux’s default OpenSSH server configuration.

The vulnerability allows an attacker to authenticate to certain password-disabled accounts using an arbitrary password between 257 and 1,024 bytes long. No knowledge of the account’s actual credentials is required.

The underlying issue dates back to 2016 and results from the interaction of password-handling behavior in OpenSSH, musl libc, and Linux account configurations. Under specific conditions, a failed password-hashing operation produces the same value used to indicate that an account has no valid password. OpenSSH mistakenly interprets the matching values as successful authentication.

The impact extends beyond traditional Linux servers. Alpine Linux is widely used in cloud environments, containers, and lightweight infrastructure, while musl-based systems also appear in routers and embedded devices.

On affected Alpine cloud images, successful authentication to a default user with passwordless doas privileges can allow an attacker to escalate to root.

The vulnerability was reported to OpenSSH by Özgün Kültekin of Wakefield. OpenSSH and Alpine Linux have released patches, and administrators should update affected systems immediately.

Alpine pushed the fix to every branch back to 3.16, including releases that are no longer supported:

You are affected if all of these are true:

Your SSH server runs on musl (Alpine, OpenWrt, Buildroot, Yocto).

It does not use PAM . Alpine’s openssh-server package doesn’t by default, or you set UsePAM no.

Password logins are on. They are by default.

There’s an account with no password set (shown as *): key-only users, LDAP users, root on Alpine.

And at least one other account on the box has a real password.

On Alpine’s official AWS and Azure images, that passwordless account is the default alpine user, and it can run doas (a lightweight sudo alternative) without a password. On vulnerable systems with this configuration, an attacker who gains access to the alpine account can effectively obtain root privileges.

The vulnerability does not affect:

Debian, Ubuntu, Fedora, and other systems using glibc rather than musl for this authentication path.

SSH servers using PAM for password authentication.

Systems with PasswordAuthentication no.

Accounts whose password field contains ! rather than *.

Containers that do not run an OpenSSH server.

Systems without the required local password-hash configuration.

Dropbear and OpenBSD’s SSH implementation.

Technical Analysis: How CVE-2026-123158 Works

The vulnerability stems from three separate software decisions made over more than a decade. Individually, each had a reasonable purpose. Together, they created a way to bypass password authentication.

1. musl libc: A Password-Length Limit

Linux systems store password hashes in /etc/shadow. When a user attempts to authenticate, the SSH server checks the supplied password against the stored hash.

On musl libc, the crypt() password-hashing function refuses inputs longer than 256 bytes, a limit intended to prevent excessively long passwords from consuming unnecessary processing resources.

When hashing fails because the password exceeds that limit, musl returns the string *.

That value is significant because Linux also uses * in /etc/shadow to indicate that an account has no valid password hash and should not accept password authentication.

2. OpenSSH, 2016: A Change to Prevent Username Enumeration

In 2016, OpenSSH introduced password-checking behavior intended to reduce information leaks that could help attackers determine whether a username exists.

As part of that behavior, OpenSSH could perform a password-hashing operation using settings obtained from another account, even when the target account had no valid password hash.

On musl-based systems without PAM, this created an unexpected interaction with musl’s handling of excessively long passwords.

3. Alpine Linux, 2022: Password-Disabled Accounts

Beginning with Alpine Linux 3.16, the default root account used * in its password field, allowing SSH key authentication while preventing ordinary password logins.

Other accounts, including key-only users and the default user on certain Alpine cloud images, can also have this configuration.

This created the final condition necessary for the bypass.

How the Authentication Bypass Happens

When an attacker submits a password longer than 256 bytes to an eligible account whose stored password field is *, the following sequence occurs:

The SSH server receives the authentication request.

musl’s crypt() function rejects the oversized password and returns *.

OpenSSH compares the returned value with the target account’s stored password field.

The comparison succeeds, and the server accepts the login.

The attack requires no password guessing, stolen credentials, or repeated authentication attempts. When all vulnerable conditions are present, a single login attempt can succeed.

This is not a cryptographic weakness or a memory-corruption vulnerability. It is an authentication logic failure caused by the interaction between two components that interpret the same value differently.

How OpenSSH Fixed the Vulnerability

OpenSSH 10.6p2 prevents the authentication bypass by rejecting stored password hashes that are too short to represent a valid hash.

As a result, the * returned by a failed hashing operation can no longer be mistaken for a legitimate password match.

Update OpenSSH and restart it. On Alpine, run apk upgrade -U -a, then rc-service sshd restart. Updating the package alone doesn’t replace the SSH server that’s already running.

Can’t update yet? Turn off password logins. Make sure your SSH key works first, then run echo “PasswordAuthentication no” > /etc/ssh/sshd_config.d/00-no-passwords.conf and restart sshd.

Rebuild your images. Patching a running server isn’t enough if your Docker or cloud images still have the old package. Rebuild them from a fixed base and redeploy.

Check if someone already got in. /var/log/messages for Accepted password for on an account that has no password (alpine, root, key-only users). If you find one, treat the machine as compromised.

Block off public and unused ports, enforce VPN connections if possible to reduce the login bypass attack surface.

Be wary of PoCs and “checker” scripts. Do not clone or run unverified exploit or scanner scripts from public repos or social media; trust the OpenSSH release and your distribution’s official packages.

For ten years, this bug went unnoticed, which is both surprising and a little absurd when you think it. This is exactly the kind of thing you’d expect to find in a regular QA session, where someone inevitably asks, “What happens if we try a really weird password?”

Looking at the research documented at sshhole.com , it took a brute-force approach to find it: building sshd in every combination of glibc, musl, PAM and no PAM, then throwing roughly 17,600 deliberately unusual login attempts at each build. Every build behaved the same except one: musl without PAM, which said yes when it should have said no.

The bug wasn’t hiding in some clever cryptography. It was sitting in the boring glue between OpenSSH and libc, the code few people bother to read. And all it took to expose it was a question as simple as: “What if the password is really long?”

We’re probably going to see a lot more of this. AI is making it possible to test software in ways that used to require the patience, curiosity and slightly obsessive mindset of hackers in the ’90s. Old software, weird edge cases, combinations nobody thought to test. There’s probably a lot more hiding in plain sight.