SSHole Just Let Attackers Log Into Alpine Servers With No Password — Here's How to Check Yours Tonight (November 2026)

I have patched a lot of servers in my life, and I have never seen a vulnerability announcement that reads quite like this one. On November 5, 2026, OpenSSH maintainer Damien Miller posted an emergency release, version 10.6p2, and his message to anyone running a particular kind of Linux system was blunt: stop reading and turn off password authentication or disable SSH immediately.

The flaw is tracked as CVE-2026-123158, nicknamed "SSHole", and it is a password authentication bypass in sshd — the server that handles your SSH logins. Under the right conditions, an attacker can log in to an account that has no password set, simply by sending a very long password. No credentials. No brute force. No clever exploit chain. Just a long string, and the door opens.

I spent the last couple of days reading the advisories, the OpenSSH release notes and the Alpine security tracker, because the first wave of coverage made it sound like every Linux server on the internet was wide open. It is not — but the servers that are affected are affected badly, and plenty of developers who run WordPress sites in Docker containers run exactly the setup this bug needs.

What SSHole actually does

SSHole is a password authentication bypass in OpenSSH's sshd, and it only exists on Linux systems where sshd is built against musl libc and runs without PAM (Pluggable Authentication Modules). In practice, that means Alpine Linux — the lightweight distribution behind an enormous number of Docker images — plus containers and embedded devices built the same way.

Here is the chain of events, as simply as I can put it. Some accounts on a system have no usable password at all — their password field is just an asterisk (), meaning "this account cannot log in with a password, ever". Service accounts and key-only accounts often look like this, and it is a deliberate, normal setup.

The bug lives in how musl's crypt() function reports a failure, and in how sshd interpreted that failure. When an attacker sent a password between roughly 256 and 1024 characters long against an account with a password field, the check that should have said "no, this account has no password" instead came back as a match.

The fix in OpenSSH 10.6p2 is simple: sshd now rejects a password match whenever the stored hash is shorter than four characters. A is one character, so it can never match again. The flaw was reported by Özgün Kültekin of Wakefield, disclosed on the oss-security mailing list on November 5, 2026, and fixed the same day. It carries a CVSS 3.1 score of 8.1 (High) and is classified as CWE-394 — an unexpected status code, which is a dry way of saying a function returned "fine" when it should have returned "no".

Who is actually affected (and who is not)

This is the part most early coverage got wrong, so let me be precise. All of the following have to be true for a server to be exploitable:

1. sshd runs on musl libc, not glibc. Alpine Linux is the big one. Most mainstream server distributions — Ubuntu, Debian, RHEL and their derivatives — build sshd against glibc.
2. sshd does not use PAM. Alpine's plain openssh-server package is built without PAM, and any build can also be configured with UsePAM no.
3. Password authentication is on. The sshd_config manual gives PasswordAuthentication a default of yes, so this is true unless you deliberately turned it off.
4. An account exists with a password field of exactly . On a default Alpine install, this is common.
5. At least one other account on the system has a real password hash (a $5$ or $6$ hash, per Alpine's advisory). This is the detail that surprises people: the bug needs a second account with a real hash present for the comparison to go wrong.

If even one of those conditions is false, the CVE as published does not apply to that sshd. Damien Miller confirmed it himself: the bug does not exist on non-Linux systems, on Linux with glibc, or on Linux systems that check passwords through PAM. So if your site runs on a standard Ubuntu or Debian VPS from a managed host, or on shared hosting, you are almost certainly outside the scope. Red Hat has stated its products are not affected.

But here is why I am writing about it on a site for WordPress and Elementor developers: Alpine is everywhere in our world. It is the default base image for a huge share of Docker containers — the slim images for Nginx, PHP and Node that we pull without thinking twice. Plenty of us run a small Alpine VPS, and plenty of CI runners and staging boxes are Alpine. An Alpine container running sshd with password authentication enabled — a jump box, a staging server, a development container someone exposed — is exactly the target.

Exploitation started within hours

One more reason not to sit on this: the window between disclosure and real-world abuse was measured in hours, not weeks. The Hacker News, citing Previdian, reported a first exploitation attempt less than nine hours after the CVE was published, with root access confirmed on an Alpine honeypot. Public reproduction labs already exist, so anyone can test the exploit — against their own systems, and against yours.

That speed is the new normal for a bug this simple to trigger. There is no complicated exploit development here — the attack is a single login attempt with a long password. The moment the details were public, every exposed Alpine sshd on the internet became a target.

How to check your servers in thirty seconds

Here is what I would run on every box I own, starting with the ones I am least sure about.

First, find out if you are on musl at all. If you are on Ubuntu, Debian, or RHEL, you can stop here — you are on glibc and outside the scope. On Alpine, cat /etc/os-release will tell you.

Second, check how sshd is configured. This one command tells you the two settings that matter:

sshd -T | grep -Ei '^(usepam|passwordauthentication)'

What you want to see on a musl system is passwordauthentication no. If it says yes and usepam no, you are in the danger zone and you should treat the next section as urgent.

Third, check the package, not the version string. On Alpine, list the installed openssh package and compare it against the fixed version for your branch — Alpine published patched packages for every branch from 3.16 to edge on November 5, 2026. A version string like OpenSSH_10.0p2 on Alpine 3.22 does not mean you are unpatched, because the fix was backported. The package version is the truth.

Fourth, check your containers. This is the one people forget. Look through the images you actually deploy for Alpine bases running sshd. A WordPress site itself almost never runs sshd inside its container — but the VPS around it, the jump box, the staging container and the CI runner might. If you are not sure whether something exposes sshd, check whether port 22 is listening:

ss -tlnp | grep :22

The fix: patch, restart, then turn off password logins

The fix itself is short, but the order matters.

Step 1: upgrade. On Alpine, update the package index and upgrade everything, which pulls the patched openssh package: apk upgrade -U -a. Or use your distribution's patched package if you are on another musl-based system.

Step 2: restart sshd. This is the step people skip, and it matters: upgrading the package does not restart the running daemon. The old, vulnerable sshd keeps listening until you restart it. On Alpine: rc-service sshd restart. On other systems, systemctl restart sshd does the same job. Verify afterwards that the running process is the new binary.

Step 3: turn off password authentication. This is the mitigation the OpenSSH team itself recommended, and honestly it is the right permanent setting for almost every server a developer runs. If you cannot upgrade yet — an old branch, a frozen image, a device you cannot touch right now — this is your immediate protection. Set it in /etc/ssh/sshd_config:

PasswordAuthentication no

On Alpine 3.19 and later you can also use a drop-in file under /etc/ssh/sshd_config.d. Either way, check for other PasswordAuthentication lines in the file, including ones inside Match blocks, because a later line can override the one you just set. Then restart sshd again.

What this means for WordPress and Elementor sites

Let me bring this back to our corner of the internet. Your WordPress site itself is almost certainly not the vulnerable piece here. WordPress runs on PHP and a database; it does not run sshd. The risk is the infrastructure around the site: the VPS it lives on, the Docker host, the staging environment, the little Alpine container somebody spun up two years ago and forgot.

Conclusion

SSHole, CVE-2026-123158, is a password authentication bypass in OpenSSH that affects Linux systems running sshd on musl libc without PAM — Alpine Linux. An unauthenticated attacker can log into an account with no password set by sending a password of 256 to 1024 characters. It was disclosed and fixed on November 5, 2026, in OpenSSH 10.6p2, and exploitation attempts were reported within hours.

Most WordPress sites on standard Ubuntu, Debian or RHEL hosting are not affected. But if you run Alpine anywhere — a VPS, a Docker host, a staging box, a CI runner — check it tonight. Run sshd -T to see whether password authentication is on, upgrade to the patched package, restart sshd, and then turn password authentication off for good and use SSH keys instead.

It is a thirty-second check and a five-minute fix. Do it before someone else does the checking for you.

Frequently Asked Questions

What is SSHole (CVE-2026-123158)?

A password authentication bypass in OpenSSH's sshd, disclosed November 5, 2026. On Linux systems where sshd runs on musl libc without PAM — most notably Alpine Linux — an unauthenticated attacker can log into an account with no password set by sending a password of roughly 256 to 1024 characters. It is rated CVSS 3.1 8.1 (High) and fixed in OpenSSH 10.6p2.

Is my Ubuntu or Debian server affected by SSHole?

No. Ubuntu, Debian, RHEL and their derivatives build sshd against glibc and use PAM, so they are outside the scope. Red Hat has confirmed its products are not affected. The bug only applies where sshd runs on musl libc without PAM, which is how Alpine Linux ships its default openssh-server package.

Is my WordPress site itself vulnerable to SSHole?

WordPress does not run sshd, so the site itself is not the vulnerable piece. The risk is the infrastructure around it: the VPS, Docker host, staging server or jump box that runs sshd. If any of those are Alpine-based with password authentication enabled, they need checking and patching.

How do I fix SSHole on Alpine Linux?

Upgrade with apk upgrade -U -a, then restart sshd with rc-service sshd restart — upgrading alone does not replace the running daemon. If you cannot upgrade yet, set PasswordAuthentication no in /etc/ssh/sshd_config and restart sshd. For a permanent fix, disable password authentication and use SSH keys.

How do I know if my Alpine system is patched?

Check the installed openssh package version against the fixed version for your Alpine branch — patched packages were published for every branch from 3.16 to edge on November 5, 2026. Do not rely on the sshd -V version string alone, because Alpine backports fixes: a 3.22 system can print OpenSSH_10.0p2 while already carrying the patched package.

Was SSHole exploited in the wild?

Exploitation attempts were reported less than nine hours after disclosure, with root access confirmed on an Alpine honeypot, according to The Hacker News citing Previdian. The attack is a single login attempt, so patching quickly matters more than usual.