OpenSSH Long-Password Flaw: What Alpine Linux Admins Should Do

Q: How do I check whether my server was already compromised?

Search /var/log/messages on Alpine for "Accepted password" entries, then compare them with /etc/shadow. A password login to an account whose field is * is the warning sign. Alpine also advises reviewing doas use, new users, new files and authorized keys. If you can't rule out a login, treat the machine as compromised and rebuild it.

By Jaspal Singh November 6, 2026 Updated: November 6, 2026

A flaw in how OpenSSH and the musl C library handle failed password hashing lets attackers log in to some Linux accounts that should never accept a password, using any password over 256 characters. It mainly affects Alpine Linux servers. Updating OpenSSH and restarting sshd, or disabling password logins, closes it.

What Happened

On November 5, 2026, the OpenSSH project released version 10.6p2, describing it in its release notes as "a critical security workaround" for Linux systems that use musl libc with PAM disabled. The same day, Alpine Linux published a security advisory and new point releases: 3.21.10, 3.22.8, 3.23.8 and 3.24.4.

The bug was reported by Özgün Kültekin of the security firm Wakefield, who named it "*sshole" and published a detailed writeup. The writeup traces the exploitable behavior back to 2016. Alpine's advisory had no CVE number when it was written, and The Register reported no indication that vulnerable systems have been exploited.

Alpine says its releases from 3.16 through 3.24, plus edge, carry the bug. It published fixed packages for all of them, including branches that are no longer supported:

Alpine branch	Fixed openssh package
edge	10.6_p2-r0
3.24	10.3_p1-r2
3.23	10.2_p1-r1
3.22	10.0_p1-r11
3.21	9.9_p2-r1
3.20	9.7_p1-r6
3.19	9.6_p1-r3
3.18	9.3_p2-r4
3.17	9.1_p1-r7
3.16	9.0_p1-r6

Note that most of those fixed packages keep an older OpenSSH version number and add a patch. Checking for "10.6p2" alone would wrongly flag a patched Alpine 3.22 server, so compare against the package revision for your branch.

Why It Matters

The flaw defeats a setting administrators treat as a hard guarantee. A * in an account's password field has meant "no password can ever work here" for decades, which is why it sits on key-only deploy users and directory-service accounts. On an affected server that promise fails, and the attacker needs neither a key nor a real password. They only need the account name.

The worst case involves Alpine's own cloud images. According to the advisory, official tiny-cloud images from 3.18.11 through 3.24.3 ship an alpine user with a * password and passwordless doas, so a login there amounts to root. Those machines become exploitable once a $6$ password hash exists anywhere on the system, which can happen the moment someone sets a password for a second user. Kültekin specifically names the official AWS and Azure images. Images built from the new point releases already contain the patch, but instances launched earlier need updating by hand.

The scope is also narrow, and that matters as much. Debian, Ubuntu and Fedora use glibc and are not affected. Neither is anything that authenticates through PAM, and a container that doesn't run sshd has no exposure just because it is built on an Alpine base image. Direct root login stays blocked unless PermitRootLogin yes is set. Alpine images that use cloud-init and set PasswordAuthentication no are also safe. If you run mostly mainstream distributions, this may touch only a few appliances or small cloud instances. Our guide to the best Linux distros covers how those families differ.

The disclosure also says something about how bugs get found now. Kültekin built sshd in many combinations (glibc, musl, PAM, no PAM, shadow, no shadow) and ran about 17,600 strange logins against the builds, using what the writeup calls "agent swarms." Only musl without PAM disagreed. OpenSSH's release announcement says its team has received many AI-assisted reports and has seen bugs found by AI tools later rediscovered independently. It concludes that adversaries can likely find them too, so it will ship fixes more often rather than batching them. Expect more point releases, and plan your patching accordingly.

How It Works

No single component is simply broken here. The bypass comes from a chain of individually reasonable decisions, made years apart by different projects.

The star. Normally /etc/shadow stores a salted hash such as $6$salt$hash. To check a login, sshd hashes what you typed using that salt and compares the two strings. A bare * isn't a valid hash, so nothing should ever match it.

The failure value. The Unix specification says crypt() returns a null pointer on failure, but many programs never checked and simply crashed. So in August 2012, musl changed crypt() to return a short string instead, such as *. Weeks later, musl added SHA-256 and SHA-512 hashing with a 256-byte password cap, because long passwords make those algorithms slow enough to be a denial-of-service risk. Past the cap, hashing fails, and failure returns *.

The borrowed salt. In 2016, OpenSSH fixed CVE-2016-6210, a timing leak that revealed which usernames exist because accounts with no usable hash were rejected faster. The fix hashes the submitted password anyway, using a salt borrowed from another account. According to Kültekin's writeup, this also applies to real accounts whose field is *. OpenSSH's source shows that function searching accounts for a $-style hash and falling back to an old DES salt if it finds none. That explains why Alpine lists a local $5$ or $6$ hash as a requirement: without one, the SHA code path and its cap never come into play.

Put together, the login runs like this. An attacker submits a password between 257 and 1,024 bytes for a * account. The upper limit is OpenSSH's own MAX_PASSWORD_LEN. sshd borrows a SHA salt, musl's crypt() refuses the long input and returns *, and sshd compares that with the stored *. They match, so the login succeeds.

Alpine made this reachable on more systems in 2022. After a 2019 issue with empty root passwords in its Docker images, it had locked root with !, but without PAM that also blocks SSH keys. Version 3.16 switched to * so keys would work again.

OpenSSH's fix is small. It adds a MIN_PASSWORD_HASH_LEN of 4, so a stored field shorter than four characters can never count as a match. All accounts with valid hashes are unaffected: the flaw does not let anyone bypass a real password, because a real hash will not equal *.

To fix an Alpine system, upgrade and then restart the daemon, because upgrading doesn't replace the copy already running:

apk upgrade -U -a
rc-service sshd restart

If you can't upgrade yet, set PasswordAuthentication no in sshd's configuration and restart it. Test key-based login in a second session first, then confirm the running setting with sshd -T. Disabling password logins is common advice in hosting best practices anyway, and this is a good argument for keeping it off permanently.

What's Still Unknown

Whether anyone used it. The behavior has been present for about a decade. Kültekin says "as far as anyone knows, nobody noticed," and raises the possibility that some people got in by accident after pasting something long into a password prompt. There is no public evidence either way, and old logs may be gone.

How many machines are exposed. Nobody has published a reliable count. Exposure depends on configuration as well as version, so counting Alpine installs would badly overstate it. Custom firmware built with OpenWrt, Buildroot or Yocto is harder still to measure, since vendors choose their own SSH server and settings and may ship updates slowly. OpenWrt's usual default is Dropbear, which Kültekin lists as unaffected, so the risk there lies in builds that add OpenSSH.

Who owns the root cause. OpenSSH says the root cause sits outside sshd and calls its patch a workaround. On the oss-security list, participants are still debating this, noting that the crypt man page on Debian also describes error strings beginning with *. Whether musl changes its failure value, and whether other software compares crypt() output the same way, remains open. A Tom's Hardware headline refers to fixes for musl, but OpenSSH's notes, Alpine's advisory and the writeup don't name a specific musl patch.

One unexplained detail. The writeup says a * account "needs a wrong try first" without elaborating, and Alpine's advisory doesn't list that as a condition. Don't treat it as protection.

Frequently Asked Questions

Is my Ubuntu or Debian server affected by this OpenSSH flaw?

No, not by this flaw. Debian, Ubuntu and Fedora use glibc rather than musl, and their crypt() setup doesn't return a bare * on failure. Most of them also authenticate through PAM, which never calls crypt() for a * account. You should still install routine OpenSSH updates, but this specific bypass needs musl with PAM turned off.

Are Alpine Docker containers vulnerable?

Only if the container actually runs sshd and meets the other conditions. Alpine says container users who aren't running sshd are not affected, which covers the typical image running a single application. Containers that deliberately run an SSH server with password logins enabled should be rebuilt on the patched package, because restarting an old image brings the vulnerable version straight back.

Does this flaw let attackers bypass real passwords?

No. An account with a valid password hash still needs its correct password, because the string musl returns on failure won't equal a real hash. The bypass works only against accounts whose password field is a bare *. Locked accounts marked with ! are not affected either, according to Alpine, so the exact field value on each account matters when you audit a system.

How do I check whether my server was already compromised?

Search /var/log/messages on Alpine for "Accepted password" entries, then compare them with /etc/shadow. A password login to an account whose field is * is the warning sign. Alpine also advises reviewing doas use, new users, new files and authorized keys. If you can't rule out a login, treat the machine as compromised and rebuild it.

Why does a 257-character password work when a short one doesn't?

Short passwords hash normally and produce a long string that never equals *, so the login fails as it should. Beyond 256 bytes, musl's SHA hashing refuses the input and returns its failure value, which happens to be *. Length matters only because it triggers that failure. The content of the password doesn't matter, and OpenSSH rejects anything over 1,024 bytes.

Is updating the package enough to fix it?

Not by itself. Alpine warns that upgrading doesn't replace the sshd process already running, so you need to restart the service afterward. Also check the package against the fixed revision for your branch, as most branches received a backported patch rather than version 10.6p2. For cloud fleets, update running instances as well as your base images, because old images stay vulnerable.

Do I need to turn off password logins if I've patched?

The patch closes this bypass, so it isn't strictly required. Key-only access is still a sensible default for internet-facing servers, since it removes a whole class of guessing and credential attacks. Alpine's mitigation uses the same setting, so adopting it costs little if your users already have keys. Test a key login in a second session before you restart sshd.