OpenSSH sshole (CVE-2026-123158): Check Your Alpine Servers

Last updated: 10 November 2026. Sources are listed at the end.

OpenSSH 10.6p2 came out on 5 November 2026 with one security fix: a password bypass in sshd, tracked as CVE-2026-123158 and nicknamed “sshole”. It only works on Linux systems that use the musl C library and check passwords without PAM. Alpine Linux is the common example. On 9 November CISA added the CVE to its Known Exploited Vulnerabilities catalog, and the SANS Internet Storm Center saw SSH login attempts with very long passwords jump from 58 on 4 November to 713 on 6 November.

If your servers run Ubuntu, Debian, RHEL or another glibc distribution with PAM, this bug does not apply to you. The machines to look at are Alpine VMs, Alpine-based containers that run their own sshd (jump boxes, SFTP and Git containers, self-hosted PaaS nodes), and small appliances. This guide shows how to tell in about five minutes, how to fix it, and how to check whether someone already got in.

Want key-only SSH on every server? The SSH Hardening Pack (₹99) has tested sshd_config drop-ins with PasswordAuthentication no, an install script that checks your key login works before it reloads sshd, and a verify script.

The short answer

• Affected: sshd before 10.6p2 on musl-based Linux without PAM, with PasswordAuthentication yes (the default), at least one account whose password field is *, and at least one account with a $5$ or $6$ password hash.
• On Alpine, run apk upgrade -U -a and then rc-service sshd restart. The upgrade alone leaves the old sshd running.
• Can’t update today? Set PasswordAuthentication no, run sshd -t, restart sshd and confirm with sshd -T.
• Rebuild container images that run sshd on an Alpine base. Pulling a new image does nothing for containers that are already running.
• Search your auth logs for Accepted password for on accounts that should have no password, such as root, alpine or key-only users.

How the bypass works

Without PAM, sshd checks a password by passing it to crypt() together with the stored hash from /etc/shadow, then compares the result with that stored value. In musl, crypt() returns * as an error marker when the password is longer than 256 bytes. On Alpine, * is also what /etc/shadow stores for an account that has no password at all.

So when an attacker sends a 257 to 1024 byte password for such an account, the error marker matches the stored * and sshd lets them in. The CVE record says that for some account configurations “any password between 256 and 1024 characters succeeds”. The Alpine advisory adds one more condition: at least one other local account must have a $5$ or $6$ hash.

The OpenSSH release notes say the root cause sits outside sshd, but sshd can avoid being exploited through it, and 10.6p2 adds that workaround. Özgün Kültekin of Wakefield reported the bug.

Are you affected?

The Alpine advisory lists four conditions. All of them must be true:

1. sshd checks passwords without PAM. On Alpine that means the openssh-server package, or openssh-server-pam with UsePAM no.
2. PasswordAuthentication is yes, which is the default.
3. At least one account has * as its password field. Common cases are root (Alpine ships it as root:* since about 3.16), users created with adduser and no password, users set with usermod -p '*', directory-service users through musl-nscd, and the alpine user in the official tiny-cloud images.
4. At least one local account has a $5$ or $6$ hash, for example after someone sets a console password or adds a user with a password.

Default PermitRootLogin prohibit-password protects root itself. With PermitRootLogin yes, root is exposed directly. Even with the default, any exposed login user who can run doas gives an attacker a route to root.

You are not affected if sshd isn’t running (most application containers), if PasswordAuthentication no is in effect, if you use openssh-server-pam with UsePAM yes, or if no account on the system has a $-style hash. Accounts locked with ! instead of * are not exploitable this way. Cloud-init setups that write PasswordAuthentication no are also fine.

Where to look first: Alpine with its own sshd tends to show up in SFTP drop boxes for clients or vendors, jump hosts built from small images, Git and CI containers, and self-hosted PaaS nodes. Coolify’s installer, for example, installs and starts sshd on Alpine hosts without turning off password logins, and a discussion on its GitHub from 7 November proposes changing that.

Watch the official tiny-cloud images. Those from 3.18.11 to 3.24.3 ship an alpine user with password * and passwordless doas. They are safe on first boot and become exploitable as soon as any $6$ hash appears, for instance when you set a console password or pass a user with hashed_passwd in user-data.

A five-minute check

This script only reads. Run it as root on each host or inside each container that runs sshd. It prints the sshd version, whether sshd is linked against musl, the three settings that matter, and the two account lists from the conditions above.

#!/bin/sh
# Quick exposure check for CVE-2026-123158 ("sshole"). Run as root. Read-only.
SHADOW=${SHADOW:-/etc/shadow}
echo "== sshd version";  sshd -V 2>&1 | head -1
echo "== C library";     if ldd "$(command -v sshd)" 2>&1 | grep -qi musl; then echo "musl (check further)"; else echo "not musl (glibc): not affected by this bug"; fi
echo "== Effective settings"; sshd -T 2>/dev/null | grep -Ei '^(usepam|passwordauthentication|permitrootlogin) '
echo "== Accounts with '*' as password field"; awk -F: '$2=="*" {print "  " $1}' "$SHADOW"
echo "== Accounts with a \$5\$ or \$6\$ hash";   awk -F: '$2 ~ /^\$[56]\$/ {print "  " $1}' "$SHADOW"

We ran it on an Ubuntu 24.04 lab box (OpenSSH 9.6p1, shortened output):

== sshd version
OpenSSH_9.6p1 Ubuntu-3ubuntu13.20, OpenSSL 3.0.13 30 Jan 2024
== C library
not musl (glibc): not affected by this bug
== Effective settings
usepam yes
permitrootlogin without-password
passwordauthentication yes
== Accounts with '*' as password field
  root
  daemon
  bin
  ...

Ubuntu has plenty of * accounts too, and that is normal. It is safe here because sshd is built against glibc and goes through PAM, so the musl error path never runs. To check the account logic, we also pointed the script at a made-up Alpine-style shadow file with root:*, alpine:* and one $6$ user:

$ SHADOW=./fake-shadow ./sshole-check.sh
...
== Accounts with '*' as password field
  root
  alpine
== Accounts with a $5$ or $6$ hash
  deploy

On a real Alpine host, that combination plus “musl”, usepam no (or no PAM line at all) and passwordauthentication yes means you are exposed until you patch. We did not have an Alpine machine in this lab, so the Alpine commands below come from the Alpine advisory and are marked as such.

Fix it: update and restart sshd

From the Alpine advisory:

apk upgrade -U -a
rc-service sshd restart

Alpine published fixed openssh packages for every branch back to 3.16, including releases that are out of support. The fixed version is what to check for, so a “10.0” on 3.22 can still be patched:

The point releases 3.21.10, 3.22.8, 3.23.8 and 3.24.4 include the fix, and so do tiny-cloud images built from them. Note that 3.21 reached end of support on 1 November 2026, so plan a move to 3.23 or 3.24 even after you patch.

For other musl systems built without PAM, update to OpenSSH 10.6p2 or to your vendor’s patched build. For containers, rebuild the image from an updated base and redeploy. If you use a community image such as an “sshd” or SFTP image on Docker Hub, check its tag and changelog before you trust it. One popular image had an open issue asking for the fix on 7 November.

While you are rebuilding, ask whether the container needs sshd at all. For admin access, docker exec or kubectl exec needs no SSH server inside the container. For remote access, one hardened bastion host with key-only logins is easier to patch and watch than sshd in every container.

Can’t patch today? Turn off password logins

First confirm that your key login works, and keep your current SSH session open until a new login succeeds. Then, as root (commands from the Alpine advisory):

mkdir -p /etc/ssh/sshd_config.d
echo 'PasswordAuthentication no' > /etc/ssh/sshd_config.d/00-no-passwords.conf
sshd -t && rc-service sshd restart
sshd -T | grep -i passwordauthentication

The last line should print passwordauthentication no. Alpine reads the drop-in directory by default from 3.19. On older releases the advisory gives a sed command that edits /etc/ssh/sshd_config directly and keeps a .bak copy. Check that no Match block sets PasswordAuthentication yes again for some users; the advisory’s sed also flips those lines. To roll back, delete the drop-in file and restart sshd.

Key-only SSH is worth keeping after you patch. Our SSH hardening checklist explains how drop-in files win over the main config, which matters if a cloud image ships its own drop-in with PasswordAuthentication yes.

Check whether someone already got in

Start with the auth log. On Alpine with the default syslog that is /var/log/messages:

grep 'Accepted password for' /var/log/messages

Any password login for root, alpine or a user who only ever logs in with a key is a red flag. In a container, sshd may log to stdout instead, so check docker logs <container>. The Alpine advisory also says to review doas use, recently created users, new files and changed authorized_keys files. If you can’t rule out a login, treat the host as compromised and rebuild it rather than cleaning it.

The long passwords themselves will show up as failed logins from scanners. The SANS diary of 8 November recorded the first apparent exploit attempt on 5 November, a password made only of the letter “A”. For a quick way to spot a successful login after many failures, see our fail2ban guide.

If you find a break-in in India

The CERT-In Directions of 28 April 2022 list unauthorised access to IT systems as a reportable incident, and it has to be reported to CERT-In within six hours of noticing it. Write down the time you found it, keep the logs, and use the CERT-In incident reporting form. Our 48-hour vendor breach plan walks through the same first steps.

Related guides

• SSH Hardening Checklist for Ubuntu 24.04 (Tested Config)
• Detect SSH Brute Force Attacks with Logs and fail2ban
• Hijacked Tor Relays Stole SSH Passwords: Lessons for Every Admin
• Linux Server Hardening Checklist (2026)

Sources

• OpenSSH 10.6p2 release notes, 5 Nov 2026
• Alpine Linux advisory, OpenSSH password authentication bypass, 5 Nov 2026
• CVE-2026-123158 record and NVD entry (CVSS 3.1: 8.1)
• CISA adds four known exploited vulnerabilities to the catalog, 9 Nov 2026
• SANS ISC, Scans for Sshole Vulnerability (CVE-2026-123158), 8 Nov 2026
• openssh-portable fix commit
• Coolify discussion #12484, 7 Nov 2026
• panubo/docker-sshd issue #93, 7 Nov 2026
• CERT-In Directions, 28 April 2022
• CERT-In incident reporting form

Not sure what your servers expose? Run the free website safety check for the web side, or book our Linux server hardening and security audit and we will review your SSH setup, users and logs. Contact us for a quote.