OpenSSH SSHole Vulnerability CVE-2026-123158: Long Passwords Open Key-Only Accounts on Alpine Linux, CISA Lists It as Exploited, and the Fixed Versions to Install

A flaw in OpenSSH, the standard tool for logging in to Linux servers remotely, lets attackers into some Alpine Linux accounts with any very long password, and CISA added it to its list of exploited bugs on November 9, 2026. If your company or IT provider runs Alpine or another musl-based Linux with SSH reachable, those machines may be open without a valid password, so check and patch them this week.

Debian, Ubuntu and Fedora are not affected, according to the researcher who found it. Where the required settings do line up, Alpine says an attack "takes one connection, works every time, and needs no retries."

What is the OpenSSH SSHole vulnerability?

SSHole, tracked as CVE-2026-123158, is a password authentication bypass in the OpenSSH server (sshd). Its finder, Özgün Kültekin of Wakefield, writes it as *sshole, and you will also see SSHole and sshhole. The CVE record scores it 8.1, High.

In plain terms: an account meant for SSH keys only has * in its password field, a marker no password should match. On musl, the C library Alpine uses, password hashing returns the text * when it fails, and it fails on passwords over 256 bytes. The two values match and the login succeeds. The CVE record gives the working range as 256 to 1,024 characters; the researcher's demo uses 257 to 1,024.

OpenSSH says the root cause lies outside sshd but that sshd can avoid it. The workaround shipped in OpenSSH 10.6p2 on Thursday, November 5, 2026.

Who is affected by the OpenSSH vulnerability?

Alpine's advisory says all four of these must be true:

• sshd runs without PAM: Alpine's openssh-server package, or openssh-server-pam with UsePAM no.
• PasswordAuthentication is on, which is the OpenSSH default.
• At least one account has * as its password field, such as a key-only user or a directory-service user with no shadow entry.
• At least one local account has a real $5$ or $6$ password hash.

What about root? Alpine base images also give root a * password, but Alpine says OpenSSH's default PermitRootLogin prohibit-password protects root from this bypass. Root is directly reachable only if someone has set PermitRootLogin yes.

An ordinary account that can become root is still a route in. Official Alpine tiny-cloud images from 3.18.11 through 3.24.3 ship an alpine user with a * password and passwordless doas, and become exploitable once any $6$ hash exists on the machine.

Beyond Alpine: the researcher names OpenWrt, Buildroot and Yocto as musl-based systems to check. We did not find separate advisories from those projects. The researcher says glibc systems, anything going through PAM, Dropbear and OpenBSD are fine. Alpine adds containers with no sshd, accounts locked with !, and systems with password login off.

Is SSHole being exploited? What is confirmed and what is claimed

Confirmed: CISA added CVE-2026-123158 to its Known Exploited Vulnerabilities catalog on Monday, November 9, 2026, with a due date of November 12. That deadline binds US federal civilian agencies, not private companies, but it is a fair yardstick. CISA lists ransomware use as "Unknown."

Reported by security firms, from their own sensors:

• GreyNoise first saw exploitation at 00:46 UTC on November 7 and, as of November 9, counted 17 attack chains from six IP addresses. It counts only cases where shell commands ran on the target.
• Previdian reports 20 attempts from 13 addresses in nine countries, starting November 6. It cautions that its sensor data does "not show that the target was vulnerable or that the attempt succeeded."

Not known: how many real systems have been broken into. None of the sources we opened names a victim. Counts of SSH servers on the internet include every SSH server, not just vulnerable ones.

Proof-of-concept code is public. Previdian warns it is unverified and could contain malware, so do not run it to test your own systems.

How to fix SSHole: what to do this week

Alpine's fixed openssh packages:

Older branches carry the fix in their existing version, so go by the package revision, not by whether the number reaches 10.6. Other musl builds need OpenSSH 10.6p2 or a vendor build containing the fix.

1. List your exposure. Find every Alpine or musl system running sshd, including cloud images, containers that run sshd and vendor appliances.
2. Check the setting. Run sshd -T | grep -i passwordauthentication.
3. Check the accounts. grep -E '^[^:]+:[*]:' /etc/shadow lists * accounts, and grep -cE '^[^:]+:[$][56][$]' /etc/shadow counts real hashes.
4. Update and restart. On Alpine, run apk upgrade -U -a, then rc-service sshd restart. Alpine warns that upgrading alone does not replace the running service.
5. If you cannot update yet, set PasswordAuthentication no and restart sshd. Confirm key login works first and keep a session open while testing.
6. Confirm root settings. PermitRootLogin should not be yes.
7. Look for a break-in. Search /var/log/messages for Accepted password for on accounts that have no password. Review doas use, new users, new files and authorized keys. Alpine says that if you cannot rule out a login, treat the machine as compromised.

Why the OpenSSH flaw matters for a business

Many companies do not know which Linux sits under their hosted apps, containers and appliances. This bug lives in that layer. A successful login gives the attacker whatever that account can do, and a key-only account may also be able to reach root or company data.

The trap is an assumption many teams share: we use SSH keys, so passwords do not matter. On affected systems, an account with no password became the way in because password login was never actually turned off.

Ask whoever manages your servers one direct question: do we run SSH on musl without PAM, and is password login on? If you host your own systems, our notes on self-hosting infrastructure cover who should own that answer.

SSHole questions people are asking

Does any password work on OpenSSH now?

No. Only very long passwords work, only on accounts with * as the password field, and only on the setups listed above.

Is my Ubuntu or Debian server affected by SSHole?

The researcher says glibc systems such as Debian, Ubuntu and Fedora are fine. The CVE record lists versions before 10.6p2 on musl without PAM, so a scanner that matches only version numbers may still flag them.

Does SSHole affect Docker containers?

Alpine says containers that do not run sshd are unaffected. A container that runs sshd on an affected package needs the same checks.

Does turning off password login stop SSHole?

Yes. Alpine lists systems with password authentication disabled as not affected. Restart sshd after changing the setting.

Do I need to restart sshd after updating?

Yes. The running service keeps the old code until it restarts.

What is the CVE number for SSHole?

CVE-2026-123158. Alpine's advisory was written before the number was assigned, so it does not appear there.

The bigger lesson

This bug came from pieces that each looked reasonable: a * marker meaning no password, and an error value that happened to be the same character. Neither was a problem until they met in one build. If an account is meant to use keys only, turn password login off and verify it, rather than trusting that no password means no way in.

For help checking your servers, see security hardening or request a quote.

Get security alerts by email, with the free checklist, at our security alerts page.

Sources: OpenSSH 10.6p2 release notes; Alpine Linux advisory; researcher's report; CISA Known Exploited Vulnerabilities catalog; GreyNoise; Previdian.