A long password unlocks some Alpine Linux servers. OpenSSH SSHole (CVE-2026-123158) is now on CISA's exploited list

On some Linux servers, an attacker can log in to an account that has no password at all by typing a very long password. Any long password works. The bug is in how OpenSSH, the program most servers use for remote logins, checks passwords on Alpine Linux and other small Linux systems built on the musl C library. Researchers nicknamed it SSHole. It is tracked as CVE-2026-123158, and on Monday, Nov 9, 2026, CISA added it to its Known Exploited Vulnerabilities catalog with a federal patch deadline of Nov 12.

The fix shipped on Nov 5 as OpenSSH 10.6p2, with patched Alpine packages back to 3.16. SecurityWeek reports that Previdian sensors logged 20 exploitation attempts from 13 IP addresses between Nov 6 and Nov 8, and that watchTowr has so far seen botnets and crypto miners using it. If you run an Alpine box with SSH open to the internet, treat this as today's job, not this week's.

How to fix

On Alpine, upgrade and then restart the SSH server. The restart matters: upgrading the package does not replace the sshd process that is already running.

apk upgrade -U -a
rc-service sshd restart

Fixed Alpine packages, from the Alpine advisory:

• edge: openssh 10.6_p2-r0
• 3.24: 10.3_p1-r2 (in Alpine 3.24.4)
• 3.23: 10.2_p1-r1 (in 3.23.8)
• 3.22: 10.0_p1-r11 (in 3.22.8)
• 3.21: 9.9_p2-r1 (in 3.21.10)
• 3.20 to 3.16: 9.7_p1-r6, 9.6_p1-r3, 9.3_p2-r4, 9.1_p1-r7, 9.0_p1-r6. Alpine published these even though those branches are out of regular support.

If you build OpenSSH yourself on musl without PAM (Buildroot, Yocto, custom images), move to portable OpenSSH 10.6p2.

If you cannot update right now, turn off password logins. Make sure your SSH key works first and keep your current session open while you test a new one:

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 notes that its default sshd_config only reads that drop-in folder from 3.19 onward, so on older releases edit /etc/ssh/sshd_config directly.

Check one box in under a minute

Three things have to be true at once for a machine to be open, and you can test all three from a shell:

sshd -T | grep -iE 'passwordauthentication|usepam'
awk -F: '$2=="*"{print $1}' /etc/shadow
grep -cE '^[^:]+:\$[56]\$' /etc/shadow

You are exposed if password authentication is yes and PAM is off, the second command prints an account that can log in, and the third prints 1 or more. The third one is the part people miss: a single account with a normal password, even a console-only one, is what makes every no-password account reachable.

To look for a break-in, Alpine suggests searching /var/log/messages for Accepted password for followed by an account that has no password, such as alpine, root or a key-only user. If you find one, Alpine's advice is to treat the machine as compromised.

What actually goes wrong

When sshd is built without PAM, it checks a password by running the attempt through the C library's crypt() function and comparing the result with the stored entry in /etc/shadow. An account with no password stores just *, which is too short to hold a salt, so sshd borrows the salt from another account's hash.

musl's crypt() gives up on inputs longer than 256 bytes and returns the string * as its error value. That is exactly what the no-password account has on file. The strings match and sshd lets the attacker in. Alpine says it takes one connection, works every time and needs no retries. The password just has to be between 257 and 1024 bytes.

The OpenSSH team says in the 10.6p2 notes that they consider the root cause to be outside sshd, but it is reachable through sshd, so they worked around it there. That is also why CISA's catalog describes it as an "unexpected return value" bug rather than a classic memory flaw.

Who is exposed in practice

The accounts most likely to be hit, per Alpine:

• The alpine user in the official tiny-cloud images (3.18.11 through 3.24.3). It has no password and passwordless doas, so a login there becomes root. These images are safe on first boot and become exploitable as soon as any $6$ hash exists, for example when someone sets a console password or user-data adds a user with hashed_passwd.
• Key-only users created with adduser and no password.
• Directory users coming through musl-nscd (nslcd, winbind, sssd), since they have no shadow entry.
• root, which ships as root:*. The default PermitRootLogin prohibit-password protects it, so root is only directly reachable if someone set PermitRootLogin yes.

The developer-tool angle is self-hosted infrastructure. Alpine is a favorite base for small VPS images, SSH bastions, SFTP drop boxes and SSH-in-a-container images. A Coolify discussion points out that its installer can add and start OpenSSH on Alpine without turning off password logins, and that Coolify passing PasswordAuthentication=no on its own client side does nothing for the server. On a box that manages your containers, an SSH login is effectively the keys to everything Docker can touch.

Who is not in scope

• Most Linux servers. Debian, Ubuntu, RHEL and other glibc distributions are not named in any advisory. The bug needs musl's crypt() behavior.
• Alpine systems running openssh-server-pam with UsePAM yes.
• Any system with PasswordAuthentication no. Cloud images configured through cloud-init write that setting, according to Alpine.
• Docker and other containers built on Alpine that do not run sshd. Alpine calls this out explicitly. Your Node or Python image on alpine is fine unless you added an SSH server to it.
• Locked accounts with ! in the password field, and machines where no account has a $-style password hash.
• OpenWrt routers on the default Dropbear SSH server. Only builds where someone installed OpenSSH's server package are in question.

What this is not

This is not a bug in the SSH protocol and not remote code execution: it is a login bypass that only works when password logins are on, PAM is off, and the box has both a no-password account and at least one normal password hash.

Evidence and sources

The HOL Guard CVE-2026-123158 record is the evidence pack and source record for this issue. This post is the operator write-up.

• OpenSSH 10.6p2 release notes (Nov 5, 2026)
• openssh-portable commit 4353fdc (the sshd workaround)
• Alpine Linux security advisory (fixed packages, affected accounts, log check)
• NVD CVE-2026-123158 (CVSS 3.1 8.1 High from MITRE)
• CISA KEV entry (added Nov 9, 2026, due Nov 12, CWE-394)
• SecurityWeek: Hackers Exploiting SSHole Authentication Bypass in OpenSSH

What do people ask about the OpenSSH SSHole bug?

Which OpenSSH version fixes CVE-2026-123158?

Portable OpenSSH 10.6p2, released Nov 5, 2026. On Alpine, the fixed packages are openssh 10.6_p2-r0 on edge, 10.3_p1-r2 on 3.24, 10.2_p1-r1 on 3.23, 10.0_p1-r11 on 3.22 and 9.9_p2-r1 on 3.21, with fixes back to 3.16. Restart sshd after upgrading.

Is Ubuntu or Debian affected by SSHole?

Not according to the OpenSSH and Alpine advisories. The bug needs the musl C library with PAM turned off. Ubuntu, Debian and other glibc distributions are not named as affected.

Are Alpine Docker images affected?

Only if the container runs an SSH server with password logins on. Alpine says containers that do not run sshd are not affected.

Is CVE-2026-123158 being exploited?

Yes. CISA added it to the Known Exploited Vulnerabilities catalog on Nov 9, 2026, and SecurityWeek reports exploitation attempts seen by Previdian, watchTowr, GreyNoise and Defused starting Nov 6.

What can I do if I cannot update OpenSSH today?

Set PasswordAuthentication no in your sshd configuration, check it with sshd -T, and restart sshd. Confirm your SSH key login works first so you do not lock yourself out.