SSHhole (CVE-2026-123158): The OpenSSH Login Bypass on Alpine Linux

What happened

SSHhole (CVE-2026-123158, CVSS 8.1) was disclosed on 5 November 2026. It affects SSH servers on Alpine Linux and similar systems, and lets an attacker log into accounts that are meant to have no password simply by typing a very long password, over 256 characters. The system mishandles the long password, and the result happens to match how those accounts are stored, so the login succeeds.

Alpine’s official AWS and Azure images are the biggest risk. Their default alpine user has passwordless doas, so one login attempt can give an attacker full root. No attacks have been confirmed yet, but public reproduction labs already exist.

How to check if I’m impacted

You’re impacted only if all of these are true:

Condition	How to check
sshd runs on musl (Alpine, OpenWrt, Buildroot, Yocto, many container images)	ldd $(command -v sshd) | grep musl returns a result
sshd doesn’t use PAM (Alpine’s default)	sshd -T | grep -i usepam shows no or nothing
Password logins are on (OpenSSH’s default)	sshd -T | grep -i passwordauthentication shows yes
One account has no password and another has a real one	grep ':\*:' /etc/shadow lists accounts, and other lines start with $6$ or $5$ hashes

Debian, Ubuntu, RHEL and other glibc systems aren’t affected.

Fix it

Step	What to do
Patch	Run apk upgrade -U -a to get OpenSSH 10.6p2 or your branch’s fixed package (for example 10.3_p1-r2 on Alpine 3.24).
Restart	Run rc-service sshd restart. The running service keeps the old code until you do.
Disable passwords	Add PasswordAuthentication no to /etc/ssh/sshd_config.d/00-no-passwords.conf, check the config with sshd -t, then restart sshd. Keep this in place after patching.
Rebuild images	Rebuild container images on a patched base.

Check for unauthorised access

Look for accepted logins, from any user, from IP addresses you don’t recognise. Password logins to accounts that should only use keys matter most. Logs are in /var/log/messages on Alpine and /var/log/auth.log on Debian and Ubuntu.

# Count accepted logins by user, IP and method
zcat -f /var/log/messages* | grep 'sshd.*Accepted' \
  | sed -nE 's/.*Accepted ([a-z-]+) for ([^ ]+) from ([^ ]+) port.*/\2 \3 \1/p' \
  | sort | uniq -c | sort -rn

# Accounts that should never accept a password
grep ':\*:' /etc/shadow

If an account from the second command shows an Accepted password login, treat it as a strong sign of exploitation. Then look for what the attacker did next:

What to look for	Where to check
New SSH keys	authorized_keys files in /root/.ssh/ and each user’s ~/.ssh/
New users	/etc/passwd and /etc/shadow
Privilege or persistence changes	/etc/doas.conf, /etc/crontabs/ and /etc/periodic/
Unfamiliar processes	ps aux and outbound connections with netstat -tnp

Don’t expose SSH to the internet

An SSH server or bastion host on the internet can be reached by anyone, so when a vulnerability like this is released it’s trivially easy for attackers to find and hit it. Take a defence in depth approach: allow SSH only from known IP addresses, or close port 22 altogether and use AWS Session Manager, Azure Bastion or a VPN instead.