By Cyber Defense Technologies November 10, 2026 4 min read
On November 9, 2026, CISA added CVE-2026-123158, an authentication bypass in OpenSSH on Linux, to its Known Exploited Vulnerabilities catalog. That means there is evidence of exploitation in the wild. Some coverage has nicknamed it "SSHole."
The flaw does not affect every Linux system running SSH. But where it applies, an attacker who can reach the SSH port can log in without a valid password, so it is worth checking today.
What goes wrong
When sshd is built or configured without PAM, it checks a password itself: it hashes the attempt with the system's crypt() function and compares the result to the hash stored for the account.
On Alpine Linux, which uses the musl C library, crypt() returns the string * as an error indicator when the password is longer than 256 bytes. That happens to be the same value stored in the password field of accounts that have no password, such as root in base images, key-only users, and some directory service accounts. sshd compares the two, sees a match, and lets the attacker in.
Per Alpine's advisory, a password of 257 to 1,024 bytes sent to an account whose password field is * is enough, provided at least one other local account has a normal $5$ or $6$ password hash. One user with a password is enough.
OpenSSH's own release notes describe the root cause as outside sshd, but exploitable through it, and the 10.6p2 release avoids it in sshd.
Are you affected?
On Alpine Linux, all of these must be true:
- PasswordAuthentication is yes, which is the OpenSSH default.
- sshd runs without PAM: the default openssh-server package, or openssh-server-pam with UsePAM no.
- At least one account has * as its password field.
- At least one other local account has a $5$ or $6$ password hash.
You are not affected if password authentication is disabled, if sshd uses PAM (UsePAM yes), if accounts are locked with ! rather than *, or if the container or system does not run sshd at all.
Cloud images need special attention. Alpine's official cloud images from 3.18.11 through 3.24.3 ship an alpine user with a * password and passwordless doas. They become exploitable as soon as any account gets a real password hash, for example when an administrator sets a console password.
Alpine is the best-documented case. If you run other Linux systems where sshd is built without PAM, including appliances and embedded devices built on musl, check with the vendor.
CVE-2026-123158 on Alpine Linux: exposed only if all are true
- PasswordAuthentication is yes (the OpenSSH default)
- sshd runs without PAM, or with UsePAM no
- At least one account has * as its password field
- At least one other account has a $5$ or $6$ password hash
- An attacker can reach the SSH port
How to fix it
- Update OpenSSH. OpenSSH 10.6p2 was released on November 5. Alpine has published fixed packages for every release from 3.16 through edge, and Alpine 3.21.10, 3.22.8, 3.23.8 and 3.24.4 include them.
- Restart sshd. Updating the package does not replace the running daemon. On Alpine: rc-service sshd restart.
- Rebuild cloud images from the fixed releases rather than patching instances one by one.
If you cannot update right away, set PasswordAuthentication no and restart sshd. Confirm the effective setting with sshd -T, and keep an existing session open while you test so you do not lock yourself out. Key-based authentication is the better long-term default for servers anyway.
Check whether you were hit
Patching closes the hole, but it does not remove an attacker who already used it. On any affected system that was reachable from an untrusted network:
- Search authentication logs (on Alpine, /var/log/messages) for Accepted password for entries on accounts that have no password, such as root, alpine or key-only users.
- Review recent doas and sudo use, new user accounts, new or changed authorized_keys files and recently modified files.
- If you cannot rule out an unauthorized login, treat the system as compromised: preserve evidence, rebuild from a known-good image and rotate any credentials it held.
The bigger lesson
This bug lives in the space between two components, each behaving as designed: a library that returns a sentinel value on error, and a daemon that compares strings. Defaults made it dangerous: password authentication on by default, accounts with * in base images, and minimal builds without PAM.
Three habits would have neutralized it everywhere:
- Disable password authentication on servers and use keys or certificates instead.
- Do not expose SSH to the internet when a VPN, bastion or zero trust access layer can front it.
- Know your base images. Containers and cloud images inherit their defaults from whoever built them, so review them like any other dependency.
How CDT can help
CDT's hardening team reviews server and image configurations against secure baselines, and our cyber hunt team can check exposed systems for signs of compromise. If you think you have already been breached, visit our under attack page.
