OpenSSH CVE-2026-123158 “SSHole”: Alpine and musl without PAM are vulnerable, but not all Linux distributions

A critical vulnerability in OpenSSH (CVE-2026-123158, nicknamed “SSHole”) is real, and a sample exploit is publicly available. However, it does not affect all Linux servers. OpenSSH servers older than 10.6p2 running the musl libc library without PAM—typically Alpine Linux—are vulnerable. According to available reports, distributions based on glibc (Debian, Ubuntu, Red Hat, SUSE) are not affected. This guide shows you how to determine if you are vulnerable and how to fix the vulnerability.

What has been verified

• Fix: OpenSSH 10.6p2 was released on November 5, 2026. According to reports, Alpine has released fixed packages for supported branches.
• What the vulnerability does: On an sshd running the musl library without PAM, an attacker who gains access to the SSH port can log in to accounts without a valid password. According to the CVE entry, for certain account configurations, any password between 256 and 1024 characters in length will work. The cause is an incorrect evaluation of whether a string matches a password hash.
• Severity: CVSS 3.1 score of 8.1 (high). The Hong Kong CERT rates it as medium, while the Hong Kong Government CERT has issued a high-level warning because a proof-of-concept (PoC) exploit exists.
• Exploitation: According to available reports, active exploitation has not been confirmed. However, a PoC exists, so it is likely that exploitation will occur.
• Discoverer: The vulnerability was reported by Özgün Kültekin of Wakefield. A fix was released within a day of the report.

What Is Not True

• “All Linux servers”: The vulnerability requires glibc without PAM. Debian, Ubuntu, Red Hat, and SUSE use glibc and, according to HKCERT, are not affected.
• “Bypassing server restrictions”: Specifically, this refers to bypassing password authentication for accounts without a valid password, not a general bypass of restrictions.
• If you log in using keys only and have passwords disabled, this attack does not affect your server.

Are you at risk? Check

All three conditions must be met simultaneously: OpenSSH prior to 10.6p2, the system uses musl libc, and sshd is running without PAM with password login enabled (default setting).

# Is it musl or glibc?
ldd --version 2>&1 | head -1

#
ssh -V

OpenSSH version# Effective
sudo sshd -T | grep -Ei 'passwordauthentication|usepam'

sshd configuration# Alpine: installed package
apk info -v openssh openssh-server 2>/dev/null

version

If the output ldd mentions musl, usepam it no and passwordauthentication is yes, you're at risk with versions prior to 10.6p2. Don't forget about containers: an image may contain an outdated package even if the host is up to date.

Fix

1. Update the package. On Alpine: sudo apk update && sudo apk upgrade openssh openssh-server and sudo rc-service sshd restart. Check the version based on the Alpine security advisories for your branch.
2. Containers. Rebuild and redeploy images that contain an older version of the openssh package. Images without a running OpenSSH server are not at risk.
3. Temporary workaround if you cannot update immediately. Add the following to your sshd configuration PasswordAuthentication no, verify it with the command sudo sshd -t , and restart the service. First, open a second connection and try logging in with a key so you don’t lock yourself out.
4. Restrict access. If possible, limit SSH to selected addresses via a firewall or VPN.

How to tell if someone has already compromised your system

• Check the logs for successful password logins (Accepted password for …), especially for accounts that aren’t supposed to have a password or aren’t in use. Passwords themselves aren’t logged, so you won’t see the attempt itself in the logs.
• Check the login history (last), unknown source addresses, and new files or keys in authorized_keys.
• If you find a suspicious login, treat the system as compromised: isolate it, change the credentials, and check what access may have been gained.

Lesson Learned

Reports indicate that the OpenSSH maintainers released a fix immediately, without a long delay in publication, because, according to them, artificial intelligence tools can rediscover reported vulnerabilities within hours. This claim is secondhand, and I have not verified it in the release notes. The conclusion, however, is clear: critical patches must be planned within hours, not weeks.

What to Take Away

Check to see if you’re running musl and OpenSSH without PAM, especially in containers. If so, update to 10.6p2 or disable passwords. If you’re using distributions based on glibc, this specific issue doesn’t affect you according to available reports, but disabling password-based login remains good practice.