What SSHole is
OpenSSH is the standard tool admins use to log in to Linux servers over the network. SSHole is a flaw in its server part, sshd, that lets attackers get past the password check. On affected systems, an attacker can log in to accounts that were meant to block password logins. These are usually accounts whose password field is set to *. Belgium's Centre for Cybersecurity rates it 8.1 out of 10.
It only affects Linux builds that use the musl C library with PAM disabled. In practice that mostly means Alpine Linux, which is very common as the base for containers (small packaged apps). Debian and Ubuntu are reported as unaffected.
How fast it was exploited
- 5 November 2026: OpenSSH 10.6p2 released with the fix.
- About 4 hours later: a public exploit (ready-made attack code) appeared.
- 7 November: GreyNoise logged the first successful attacks.
- 9 November: CISA, the US cyber defense agency, added it to its Known Exploited Vulnerabilities (KEV) list of flaws used in real attacks.
Where the account had admin rights with no password needed, attackers got full control (root). They were seen installing botnet malware, crypto miners and their own SSH keys. They also installed a remote control program so they could keep giving the server orders.
Am I affected?
Your IT team can check three things on any system that accepts SSH logins:
- Is it Alpine or another musl-based distribution? (
cat /etc/os-release) - Which OpenSSH version is running? (
ssh -Vorsshd -V). Anything before 10.6p2 on musl is in scope. - Is password authentication enabled in
sshd_config? (PasswordAuthentication)
Do not forget containers and small devices. Alpine-based images that run sshd for debugging, build servers and small network devices are easy to miss.
How to fix it
The fix is a simple update. Turning off password logins is a good stopgap.
- Upgrade OpenSSH to 10.6p2 or later through your system's package manager, then restart sshd.
- If you cannot upgrade yet, disable password authentication (
PasswordAuthentication no) and use keys only. This is good practice anyway. - Do not expose SSH to the whole internet. Put it behind a VPN or a single secured entry server (bastion host), or allow only known IP addresses.
- Rebuild container images from an updated base image rather than patching running containers.
Check whether you were already hit
Attacks started within days. So check any system that was exposed between 5 November and the day you patched:
- Unknown keys in
~/.ssh/authorized_keys, especially for root and service accounts - Successful logins for accounts that should never log in with a password
- New scheduled tasks (cron jobs), systemd services or odd programs using a lot of CPU (crypto miners)
- Connections out to unfamiliar hosts
If you find anything, treat it as an incident. Cut the server off from the network, keep the logs and rebuild from a clean image. Our incident response plan template walks through the steps, and you can contact us if you need hands-on help.
Sources
Need a hand with this?
Talk to a senior consultant. We reply within one business day with clear next steps and a scoped quote.
Written by
NextGarrison Security TeamPenetration testers, SOC analysts and compliance consultants
Our consultants test applications and networks, run 24/7 security monitoring and prepare companies for SOC 2, ISO 27001 and PCI DSS assessments. We write about what we see in real engagements, in plain English.