OpenSSH “SSHole” CVE-2026-123158 Now Actively Exploited: Who Is at Risk and What to Do

News · 12 November 2026

An OpenSSH authentication bypass nicknamed “SSHole” (CVE-2026-123158) is now being used in real attacks. On 9 November 2026 the U.S. CISA added it to its Known Exploited Vulnerabilities catalogue. The good news: only a specific kind of Linux setup is exposed. If you run your own server, here is how to tell whether yours is one of them.

What happened

The OpenSSH project released Portable OpenSSH 10.6p2 on 5 November 2026 with a fix for a password authentication bypass in sshd. It affects some Linux systems built and run without PAM support. OpenSSH says the root cause sits outside sshd, but it can be exploited through sshd.

According to SecurityWeek, the flaw is rated CVSS 8.1. On systems that use the musl C library with PAM disabled, an attacker can log in to certain accounts using any password between 257 and 1,024 characters. Alpine Linux, which uses this setup by default, said every release it checked (3.16 through 3.24 and edge) was affected and urged users to patch and restart sshd at once.

The Hacker News reports exploitation attempts since 6 November. GreyNoise saw its first attempt on 7 November and has confirmed follow-up activity: reading password hashes and root SSH keys, querying cloud metadata services, and adding attacker keys to authorized_keys for persistent access. watchTowr says the flaw is also being used for botnet and crypto-miner installs.

Who is at risk

New Zealand’s NCSC lists the conditions. A server is exposed only when all of these are true:

• OpenSSH older than 10.6p2 (or an unpatched distribution package)
• the system runs on musl libc (Alpine, OpenWrt, Buildroot, Yocto and similar)
• sshd does not use PAM
• password logins are allowed (the OpenSSH default)

According to eSentire, glibc-based distributions such as Debian, Ubuntu and Fedora, and systems that check passwords through PAM, are not affected. Typical AlmaLinux, Rocky or Ubuntu servers fall outside the risk group. Alpine-based containers, small VMs, routers and appliances are the main concern.

What to do now

1. Check your system. Run ssh -V and ldd --version. If the second command mentions musl, or cat /etc/os-release shows Alpine, keep reading.
2. Update OpenSSH to 10.6p2 or your distribution’s patched package, then restart sshd so the old daemon stops running.
3. If you cannot patch today, set PasswordAuthentication no in /etc/ssh/sshd_config and restart sshd. Make sure your SSH key login works first.
4. Look for signs of a break-in on exposed systems: unknown entries in ~/.ssh/authorized_keys (including root), new users, unknown cron jobs and unusual CPU use.

# Alpine Linux
apk update && apk upgrade openssh-server
rc-service sshd restart

# temporary mitigation if you cannot update yet
echo "PasswordAuthentication no" >> /etc/ssh/sshd_config
rc-service sshd restart

Key-only SSH login is a good habit on every server, not just this time. It shuts out password guessing as well as bugs like this one.

Need help?

Running your own Linux server? A ShoHost virtual dedicated server gives you full root access to pick a glibc distribution like AlmaLinux or Ubuntu and lock SSH down to keys. Questions? Email support@shohost.com or WhatsApp +91 94880 91432 (9 AM to 12 midnight IST).

Sources: OpenSSH release notes (5 November 2026); SecurityWeek (6 November 2026); eSentire (9 November 2026); The Hacker News (10 November 2026); NCSC New Zealand (11 November 2026).