SSHole OpenSSH Vulnerability: How to Check Alpine Servers and Containers That Run sshd

A new openssh vulnerability nicknamed SSHole lets an attacker log in to some locked accounts with a very long password, on Linux systems that use musl libc with PAM turned off. Alpine Linux is the best-known example. OpenSSH shipped a fix in version 10.6p2 on November 5, 2026, and Alpine published fixed packages for every branch back to 3.16 the same day.

The openssh vulnerability is tracked as CVE-2026-123158 with a CVSS 3.1 score of 8.1 (High). A security firm says it saw exploitation attempts within hours of the CVE going public. If you run Alpine on a VPS, an appliance, or inside a Docker container that starts sshd, this post covers how to tell whether you are exposed, how to update, and what to look for in your logs. New to CVE records? See our explainer on what a CVE is.

The short version: update the openssh package, then restart sshd, because the upgrade alone does not protect a running server. If you cannot update tonight, turn off SSH password logins. Then check your logs for password logins to accounts that should not have a password. Debian, Ubuntu, Red Hat and other glibc-based systems are not affected, according to the researcher.

What OpenSSH and Alpine say about the SSHole openssh vulnerability

OpenSSH’s release notes for 10.6p2 describe "a critical security workaround that affects Linux systems that use the musl libc and PAM disabled." The OpenSSH team says it considers the root cause to be outside sshd. It fixed the problem in sshd anyway, because the bug is exploitable through it. The notes credit Özgün Kültekin of Wakefield with the report.

The CVE record for CVE-2026-123158, published by MITRE on November 5 at 15:46 UTC, lists OpenSSH versions before 10.6p2 on Linux as affected. It says that for some account setups, any password between 256 and 1024 characters succeeds. The record scores it 8.1 with the vector AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H. That means network reachable, no login needed, and full impact, with "high" attack complexity because several conditions must line up. Our guide on how to read a CVSS score explains each part of that string.

Alpine’s security advisory, also dated November 5, is blunter. It says an attacker who can reach the SSH port may log in without a password, in one connection, reliably. Alpine said no CVE existed yet when it wrote the advisory.

How the bypass works, in plain terms

On Linux, an account’s password hash lives in /etc/shadow. A * in that field is the usual way to say "no password can ever match." Root, key-only deploy users and system accounts often carry it.

When PAM is off, sshd checks a password itself. It runs the password through the system’s crypt() function and compares the result to the stored hash. The researcher’s write-up at sshhole.com explains the catch. Musl’s crypt() returns * when it fails, instead of returning nothing. Musl’s SHA-512 code fails on passwords longer than 256 bytes. So a password of 257 characters or more produces *, which matches the locked account’s *, and sshd lets the user in.

The researcher’s site spells the name "sshhole." OpenSSH’s fix, in this commit, makes sshd reject any stored hash shorter than four characters, so a bare * can no longer match.

Who the openssh vulnerability affects, and who it does not

Alpine’s advisory lists four conditions for the openssh vulnerability. All of them must be true:

• The openssh-server package is built without PAM, or openssh-server-pam runs with UsePAM no. Alpine’s plain openssh-server package is built without PAM.
• PasswordAuthentication is on. That is the OpenSSH default.
• An account has * as its password field.
• At least one local account has a $5$ or $6$ password hash. These prefixes mark SHA-256 and SHA-512 password hashes.

Root on Alpine ships as root:*, according to Alpine. The default PermitRootLogin prohibit-password setting still protects root. But Alpine warns that a reachable non-root account that can escalate, for example through doas, can still lead to root.

Alpine also flags its tiny-cloud images. Images from 3.18.11 through 3.24.3 ship an alpine user with a * password and passwordless doas. They become exploitable once a $6$ hash exists on the machine. Images from 3.21.10, 3.22.8, 3.23.8, 3.24.4 and later include the fix.

The researcher lists other musl platforms too: OpenWrt, Buildroot, Yocto and many Docker images. Not affected, per the researcher: glibc systems, setups that check passwords through PAM, Dropbear, and OpenBSD.

Fixed versions as of November 7, 2026

Alpine’s advisory lists these fixed packages for the openssh vulnerability. We spot-checked the edge and 3.22 builds on Alpine’s package site, both built November 5.

If you build OpenSSH yourself on musl, the upstream fix is OpenSSH 10.6p2. On a backported distro package, the upstream version number will look old. Check the package release instead.

Checklist: are you exposed to this openssh vulnerability?

Run these as root on each Alpine host, and inside any container that runs sshd.

1. Confirm the platform. cat /etc/os-release shows Alpine. On other systems, ldd --version names musl if that is the C library.

2. Check the package. apk list -I | grep openssh shows installed versions. Compare them with the table above.

3. Check the settings sshd is really using. sshd -T | grep -Ei 'usepam|passwordauthentication|permitrootlogin' prints the live values.

4. *Look for `accounts.**grep -E ‘^[^:]+:*:’ /etc/shadow` lists them.

5. Look for SHA-2 hashes. grep -cE '^[^:]+:\$(5|6)\$' /etc/shadow counts accounts with a $5$ or $6$ hash.

6. Find containers that run sshd. docker ps shows port mappings. Treat any container that publishes port 22, or whose entrypoint starts sshd, as a host to check. See our post on containers for how images relate to containers.

7. Ask appliance vendors. If a firewall, NAS or router runs OpenSSH on musl, ask the vendor whether it uses PAM and when a fix ships.

If steps 1 to 5 show musl, no PAM, password logins on, a * account and a SHA-2 hash, treat the host as exposed until patched.

How to update Alpine hosts and rebuild images

Alpine’s advisory gives two commands for a host:

apk upgrade -U -a
rc-service sshd restart

For Docker, a running container does not pick up fixes from a new base image. Rebuild with a fresh pull, for example docker build --pull --no-cache, then redeploy. Pin to a fixed point release such as 3.22.8 or later, per Alpine’s list. Alpine says containers that do not run sshd are not affected, so focus on images that do.

VPS templates, golden images and CI base images built before November 5 still carry the old package. If you got a compromised update notice on any server this week, review that host first.

Temporary mitigation if you cannot patch tonight

Both Alpine and the researcher give the same stopgap for the openssh vulnerability: turn off password logins. Alpine suggests a drop-in file at /etc/ssh/sshd_config.d/00-no-passwords.conf containing:

PasswordAuthentication no

Restart sshd, then confirm with sshd -T | grep -i passwordauthentication. It should print passwordauthentication no. Alpine says to confirm your key login works first, so you do not lock yourself out.

Keep PermitRootLogin at its default prohibit-password. Alpine says that setting keeps root safe from this bug. Setting it to yes makes root reachable.

Neither Alpine nor OpenSSH lists other settings, such as MaxAuthTries, as mitigations.

Reports of exploitation, and what to look for in logs

The security firm Previdian tracks attack traffic. Its CVE-2026-123158 page shows its sensors first saw activity on November 6 at 00:05 UTC, about eight hours after the CVE was published. When we checked, it listed 17 attempts from 11 IP addresses. The page also says its telemetry shows attempts only, not whether any target was vulnerable or breached.

The Hacker News reported on November 6 that Previdian saw the first attempt "less than nine hours after the CVE publication" and confirmed root access on an Alpine honeypot. We could not find the honeypot claim on Previdian’s own page. As of November 7, the CVE record’s CISA assessment lists exploitation as proof of concept, and the researcher’s page links a public detection tool.

Alpine’s advisory says what to check on any exposed machine:

• Search /var/log/messages for sshd "Accepted password for" lines on accounts with no password, such as alpine, root, or key-only users.
• Review doas use, newly created users, recent files and authorized_keys entries.
• If you cannot rule out a login, treat the machine as compromised.

A starting command is grep 'Accepted password for' /var/log/messages. Containers often log to stdout instead, so check docker logs for those.

How the researcher found it

The researcher’s write-up says he found the openssh vulnerability by building OpenSSH several ways: glibc and musl, with and without PAM, with and without shadow passwords. He then sent about 17,600 unusual login attempts, including odd hashes, broken accounts and very long passwords. He used swarms of AI agents to run them. Every build agreed on every login except musl without PAM.

OpenSSH’s own notes point the same way. The team says it will release more often, because AI-assisted tools are finding bugs that others may find too. We covered the attacker side of AI agents in our post on ARTEX.

Frequently Asked Questions