OpenSSH Password Bypass on Alpine and musl Linux (sshhole): What WordPress Hosts Need to Check

Introduction

On November 5, 2026, the OpenSSH team released OpenSSH 10.6p2 with an emergency workaround for a critical password authentication bypass in sshd. It affects Linux systems built on the musl C library where sshd checks passwords itself instead of handing them to PAM. Alpine Linux is the main example, and its standard openssh-server package works this way out of the box.

On an affected box, accounts that are supposed to never accept a password (key-only deploy users, LDAP users, root on modern Alpine, and the default alpine user on Alpine’s AWS and Azure images) can be logged into with a long enough password. The researcher who found it, Özgün Kültekin of Wakefield, published the full story at sshhole.com.

Native GridPane, RunCloud and cPanel servers should be fine: they run glibc-based distributions (Ubuntu, AlmaLinux and friends) and route password logins through PAM, which OpenSSH says are not affected. Container-based platforms such as RunCloud’s Docker servers, Enhance and FlyWP need a closer look. The bigger risk for most WordPress shops is everything around the fleet: Alpine VMs, bastion hosts, SFTP and backup containers, Git servers, and routers or appliances running OpenSSH on musl.

The one thing to do: on any musl host running OpenSSH, update the openssh package now. If you can’t, set PasswordAuthentication no and restart sshd.

TL;DR

• What: OpenSSH sshd on musl Linux without PAM (Alpine by default) lets an over-long password into accounts that should never take one: key-only users, LDAP users, root on Alpine 3.16+, and the alpine user on Alpine’s AWS/Azure images.
• Fix: OpenSSH 10.6p2, released Nov 5, 2026, or your vendor’s patched package (Alpine has backported the fix to 3.16 and later). Container images that run sshd need rebuilding.
• Can’t patch yet: set PasswordAuthentication no and restart sshd, or restrict port 22 to trusted IPs.
• Not affected: glibc distros (Ubuntu, Debian, AlmaLinux), anything using PAM for passwords, and Dropbear. Native GridPane, RunCloud and cPanel servers should be fine; RunCloud Docker, Enhance and FlyWP are unconfirmed, so ask your provider.
• Look beyond WordPress: bastions, SFTP/backup targets, Git servers, routers and appliances are the more likely exposure (details).
• Check: any successful password login to an account whose /etc/shadow field is * means the box is compromised.
• CVE: CVE-2026-123158 (CVSS 8.1). No exploitation reported so far.

How It Works

No single project wrote “the bug”. It’s three reasonable decisions that line up badly, which is why it sat unnoticed for about ten years.

First, in 2012 musl changed crypt() to return an “unmatchable” value instead of NULL when hashing fails, because too many programs crashed on NULL. The value it picked is *. A few weeks later musl’s SHA-512 crypt got a 256-byte password cap as DoS protection; past the cap, hashing fails and you get * again.

Second, in 2016 OpenSSH fixed a username-enumeration timing leak (CVE-2016-6210). When an account has no real hash to compare against, sshd now hashes the attempt anyway using another account’s salt, so every “no” takes the same time.

Third, * in /etc/shadow is the long-standing Unix way of saying “no password login for this account”, and Alpine moved root to * in 3.16 so key logins would work without PAM.

Put those together without PAM in the middle: an over-long password for a * account gets hashed with a borrowed SHA-512 salt, musl gives up and returns *, and sshd compares * to *. They match. With PAM, the * account never reaches crypt(), which is why glibc and PAM-based systems are unaffected. We’re deliberately keeping this conceptual; the researcher’s write-up has the full detail.

sshhole.com

openssh on musl linux has been letting people into password-less accounts since 2016.

sshhole.com

According to PrivacyAffairs’ analysis, the 10.6p2 workaround has sshd refuse a match when the stored password field is shorter than four characters.

What We Know So Far

• Aug 2012: musl starts returning * from a failed crypt() and adds the 256-byte SHA-512 cap (sshhole.com).
• Jul 2016: OpenSSH’s CVE-2016-6210 fix adds the borrowed-salt path that makes the bug reachable (openssh-commits).
• 2022: Alpine 3.16 changes root’s password field from ! to * so key logins work without PAM (sshhole.com).
• Nov 4, 2026: Kültekin reportedly reports the flaw to OpenSSH (Mallory timeline).
• Nov 5, 2026: OpenSSH 10.6p2 ships. Damien Miller tells affected admins to set PasswordAuthentication=no or disable SSH immediately (Hachyderm). Alpine pushes fixed packages the same morning and backports to 3.16 (LWN). musl’s maintainer posts his own advisory (musl list).
• Nov 5, 2026 (afternoon): CVE-2026-123158 published, CVSS 8.1 (NVD).

The flaw was assigned CVE-2026-123158 (CVSS 8.1, High) later the same day. As of this writing, neither OpenSSH nor Alpine has reported exploitation in the wild (SecurityOnline). The disclosure window was about a day. OpenSSH’s release notes say AI-found bugs are increasingly being rediscovered independently, so it is shipping fixes faster rather than holding long embargoes. Treat “no known exploitation” accordingly.

Both projects say the root cause isn’t theirs: OpenSSH puts it outside sshd, and musl’s maintainer says it is not a musl vulnerability. For your purposes it doesn’t matter. The fix is in the openssh package.

Who’s exposed: hosts running OpenSSH on musl (mainly Alpine, plus some OpenWrt, Buildroot and Yocto builds) where sshd doesn’t use PAM and password logins are on, which is OpenSSH’s default. The accounts at risk are the ones with no password set, such as key-only users and root on modern Alpine. The worst case is Alpine’s AWS and Azure images, whose default alpine user can become root without a password.

Not affected: glibc-based Linux (Ubuntu, Debian, AlmaLinux and the like), anything that checks passwords through PAM, non-Linux systems, and Dropbear. Alpine has fixed packages for 3.16 and later.

WordPress Hosting Providers and Control Panels

The question for any platform is narrow: does the sshd process that checks the password run on musl without PAM? Where a user’s login is checked doesn’t have to be where they end up. Many panels run sshd on the host operating system and only then drop the user into a container. If that host is Ubuntu, Debian or AlmaLinux, the password check goes through glibc and PAM and isn’t affected, even when the container the user lands in is Alpine.

Here’s where things stand for the platforms our readers use most. “Not expected” means the published architecture points to a glibc host sshd; “Ask” means we couldn’t confirm from public docs how SSH is served.

Platform	How customer SSH works	Exposure
GridPane	sshd on the Ubuntu host	Not expected
RunCloud (native)	sshd on the Ubuntu host	Not expected
RunCloud (Docker / containerized)	RunCloud’s rc-shell creates a per-user container when a system user connects over SSH or SFTP	Ask RunCloud. Likely fine if the login is checked by the host’s sshd before the container starts, but not confirmed
Enhance	SSH users are placed inside their website’s application container; per-site password SSH can be switched on in the panel	Ask Enhance (or your Enhance-based host). Password SSH being a customer feature makes this one worth a direct answer
FlyWP	Docker-based, each site in its own container, with site-specific SFTP	Ask FlyWP. We couldn’t confirm which image serves SFTP
cPanel/WHM, Plesk, DirectAdmin, CloudPanel, HestiaCP, CyberPanel	sshd on a glibc host (AlmaLinux, CloudLinux, Debian, Ubuntu) with PAM	Not expected
Managed WordPress hosts (Kinsta, WP Engine, Cloudways and similar)	Provider-controlled	Check the provider’s status page or ask support

If you need to ask a provider, three questions get you a useful answer:

1. Does the sshd that customers connect to for SSH or SFTP run on musl (Alpine or similar), and is it built or run without PAM?
2. Is password authentication enabled for customer SSH or SFTP?
3. Has it been updated to OpenSSH 10.6p2 or the patched Alpine package?

We’ll update this section as providers respond.

Provider Responses

• GridPane: Ubuntu-based (glibc, PAM). No statement seen as of Nov 5, 2026.
• RunCloud: native servers are Ubuntu-based (glibc, PAM). Docker servers drop SSH/SFTP users into per-user containers; not yet confirmed. No statement seen as of Nov 5, 2026.
• Enhance: SSH users land inside their website’s container, and per-site password SSH can be enabled; not yet confirmed. No statement seen as of Nov 5, 2026.
• cPanel/WHM: AlmaLinux, CloudLinux and Ubuntu (glibc, PAM). No statement seen as of Nov 5, 2026.

Infrastructure Beyond WordPress

Most of the real exposure is likely to sit next to your WordPress fleet rather than in it: the small boxes and containers that run supporting services. Alpine is popular exactly where people want something tiny and forget about it. Worth checking:

• Bastion and jump hosts. Small Alpine VMs whose only job is SSH are the textbook case, especially ones built from Alpine’s AWS or Azure images with the default alpine user.
• SFTP and backup targets. Containers that accept client uploads or backup pushes over SFTP. The popular linuxserver/openssh-server image is Alpine-based but uses the PAM build with password logins off by default; if you turned passwords on, check that UsePAM is yes.
• Git servers. The official Gitea (and Forgejo) Docker images are Alpine and run OpenSSH for git-over-SSH. Gitea’s bundled sshd_config sets PasswordAuthentication no and only allows the git user in the versions we checked, so a default install should be fine; a customized config may not be.
• Self-hosted tools in Docker. Monitoring, log collectors, status pages, dev containers and CI runners built on alpine that someone added sshd to for convenience.
• Routers, VPN and network gear. OpenWrt ships Dropbear (not affected) unless you swapped in OpenSSH. Appliances built on Buildroot or Yocto often use musl, and you can’t easily tell which SSH server they run, so ask the vendor.
• NAS boxes, IoT and embedded devices with SSH enabled: same as above, ask the vendor or check the SSH banner and firmware notes.

Not affected, for reference: Proxmox VE and other Debian-based hypervisors, Ubuntu or RHEL-family database and mail servers, and pfSense or OPNsense firewalls, which run FreeBSD.

What To Do

The exact steps depend on your operating system, images and providers, so this is the order of operations rather than vendor-by-vendor commands.

1. Find what’s exposed. Any host, container or appliance running OpenSSH on musl with password logins on and PAM not in use. The provider and infrastructure sections above are your checklist.
2. Update OpenSSH. Install OpenSSH 10.6p2 or your vendor’s patched package. Containers need rebuilding from a patched image, not just a restart.
3. Can’t update yet? Turn off password logins. OpenSSH’s own advice is PasswordAuthentication no (confirm key login works first), or stop sshd or limit it to trusted IPs until you can patch.
4. Ask your providers wherever they run SSH for you, using the questions above.
5. Check whether it was already used. A successful password login to an account whose password field is * should never happen; if you find one, treat the machine as compromised. The researcher’s write-up includes a quick log check.

For the full process, see How to Check a Linux Server for Intrusion: A Step-by-Step Process.

FAQ

I only use SSH keys. Am I safe?

Not unless password authentication is actually off. Key-only accounts usually have * as their password field, which is exactly what this bug targets. Using keys yourself doesn’t stop sshd from accepting a password attempt.

My WordPress containers use Alpine images. Do I need to do anything?

Only if they run sshd. A typical wordpress:fpm-alpine or nginx:alpine container doesn’t, so there’s nothing for this bug to reach. Rebuild anything that does.

Is Dropbear affected?

No, according to both the Alpine and musl maintainers who checked its source.

Is there a CVE?

Yes. It was assigned the afternoon of November 5, 2026 as CVE-2026-123158, rated 8.1 (High). NVD analysis was still pending at the time of writing, so vulnerability scanners may take a while to flag it. Don’t wait for them before patching.

Updates

• November 5, 2026: Initial post.

Sources

• sshhole.com: researcher write-up by Özgün Kültekin (Wakefield)
• OpenSSH 10.6p2 release notes
• NVD: CVE-2026-123158
• Damien Miller’s announcement on Hachyderm
• Rich Felker: Advisory for OpenSSH+musl users (musl mailing list)
• LWN: Critical security vulnerability affects OpenSSH on Alpine Linux systems
• PrivacyAffairs: OpenSSH 10.6p2 Fixes Password Bypass on Alpine Linux
• SecurityOnline: OpenSSH Authentication Bypass on Alpine Linux
• LAVX News: OpenSSH 10.6p2 patches critical vulnerability
• Mallory: disclosure timeline
• RunCloud: Docker Container FAQs (rc-shell)
• Enhance community: SSH users are placed in their application container
• Verpex KB: Configuring SSH access in Enhance (password authentication option)
• FlyWP: Docker-based architecture
• Gitea Docker sshd_config (mirror)
• linuxserver/docker-openssh-server: Alpine base and openssh-server-pam
• OpenSSH commit for CVE-2016-6210 (2016)
• musl commit b3c4cc12 (2012)