SSHole OpenSSH Bypass (CVE-2026-123158): Alpine Fix in 8 Steps

Updated 10 November 2026. CISA added SSHole to its Known Exploited Vulnerabilities catalog on 9 November, and GreyNoise now counts 18 successful exploitation chains.

SSHole (CVE-2026-123158) is a password authentication bypass in OpenSSH's sshd on Linux systems that use musl libc without PAM, and Alpine Linux is the main example. On an affected server, a password longer than 256 bytes can log in to an account whose password field is set to *, which is supposed to mean that no password works. OpenSSH shipped a workaround in version 10.6p2 on 5 November 2026, and Alpine published an advisory with patched openssh packages for every branch the same day.

Attackers moved fast. GreyNoise logged the first public exploit about four hours after the release and the first successful break-in on 7 November, and CISA listed the flaw as exploited on 9 November. If you run sshd on Alpine, update openssh and restart sshd today, or turn off password logins until you can. Standard Debian, Ubuntu and Fedora servers, which check passwords through PAM on glibc, are outside the attack path the researcher describes.

Related: Rails 8.1.4.1 Security Release: 21 Fixes and How to Upgrade

SSHole at a glance

What is SSHole?

SSHole is a chain of old, sensible decisions that fail together. The researcher's write-up at sshhole.com and a 6 November post by musl maintainer Rich Felker explain it:

• Accounts that should never accept a password, such as key-only users, carry a * in the password field of /etc/shadow. No real password hash can equal *.
• To avoid revealing which accounts have passwords, sshd still runs a password check for such accounts. It borrows the hash of the first account in /etc/passwd order that has a real password and uses it as the salt.
• When musl's crypt() fails, it returns the string * instead of nothing. Its SHA-256 and SHA-512 code fails on keys longer than 256 bytes.
• So a long enough password makes crypt() return *, which matches the stored *, and sshd lets the attacker in.

The OpenSSH team says it considers the root cause to be outside sshd, but it fixed sshd anyway. The 10.6p2 change makes sshd refuse any stored hash shorter than four characters, so * can no longer match. Felker also plans to switch musl's failure value to the *0 and *1 convention that other crypt() libraries use, a change that distributions can backport.

Am I affected by SSHole?

Alpine's advisory says you are affected only if all four of these are true:

1. You run Alpine's openssh-server package, which is built without PAM, or openssh-server-pam with UsePAM no.
2. PasswordAuthentication is yes, which is the default.
3. At least one account has * as its password field. That includes key-only users, directory-service users and, in base images since about Alpine 3.16, root, although root stays shielded by the default PermitRootLogin prohibit-password.
4. At least one local account has a SHA-256 or SHA-512 password hash, which starts with $5$ or $6$.

Affected releases are Alpine 3.21 to 3.24 and edge, plus the unsupported 3.16 to 3.20. You are not affected if password logins are off, if you use openssh-server-pam with UsePAM yes, if the account is locked (its password field starts with an exclamation mark), or if no account on the machine has a $-style hash.

Are Alpine Docker containers affected?

Only if sshd runs inside the container, Alpine says. Check images that install openssh-server on purpose, such as SSH bastion, SFTP, CI runner and remote development images, then rebuild them on a patched base and redeploy.

Alpine cloud images and self-hosted platforms

Alpine warns that its official tiny-cloud images from 3.18.11 through 3.24.3 ship an alpine user with a * password and passwordless doas. Once any $6$ hash exists on such a machine, an SSHole login on that user becomes root. Images built from 3.21.10, 3.22.8, 3.23.8, 3.24.4 and later are fixed. A Coolify discussion from 7 November notes that its Alpine installer starts sshd without setting PasswordAuthentication no, and that the client-side option does not change the server.

What about Debian, Ubuntu and Fedora?

The researcher says glibc systems that go through PAM, such as Debian, Ubuntu and Fedora, are not affected, because PAM never calls crypt() for a * field, and Felker adds that Dropbear is not affected either. Ubuntu's security team rates the CVE High but notes that Ubuntu does not use musl by default. Debian's tracker, as of 10 November 2026, lists the bookworm and trixie packages as vulnerable and the fix as 1:10.6p2-1 in forky and sid. Install those updates when they arrive, but patch musl hosts first.

How to check an Alpine server in two minutes

Run these as root on every host that runs sshd. They only read files and settings.

# Alpine release and installed openssh packages
cat /etc/alpine-release
apk info -v | grep openssh

# Is password login on? Look for "passwordauthentication yes"
sshd -T | grep -i passwordauthentication

# Accounts whose shadow password field is exactly *
awk -F: '$2 == "*" {print $1}' /etc/shadow

# Accounts with SHA-256 or SHA-512 hashes ($5$ or $6$)
awk -F: 'substr($2,1,3) == "$5$" || substr($2,1,3) == "$6$" {print $1}' /etc/shadow

If password authentication is yes and both awk commands print at least one user, treat the host as exposed until it runs a fixed package. Compare the installed openssh version with Alpine's list:

Stable branches get the fix as a backport, so check the Alpine package release, such as -r11, not the OpenSSH version that ssh -V shows.

How to fix SSHole in 8 steps

1. Keep a session open. Before you touch sshd, confirm that key login works in a second SSH session, so a mistake cannot lock you out.
2. Upgrade the packages. Run apk upgrade -U -a, the command in Alpine's advisory. It also installs any other pending updates, so test critical hosts first if you can.
3. Restart sshd. Upgrading the package does not restart the running daemon. Run rc-service sshd restart.
4. Verify. Run apk info -v | grep openssh again and compare the result with the table above.
5. Turn off password logins if you do not need them. This blocks SSHole even on an unpatched host. Alpine's steps, as commands:

   # Back up the main config
   cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak
   
   # Drop-in file (Alpine 3.19 and later; skip on older releases)
   echo "PasswordAuthentication no" > /etc/ssh/sshd_config.d/00-no-passwords.conf
   
   # Set every PasswordAuthentication line in the main file to no
   sed -i 's/^[#[:space:]]*PasswordAuthentication.*/PasswordAuthentication no/' /etc/ssh/sshd_config
   
   # Test, restart and confirm
   sshd -t && rc-service sshd restart
   sshd -T | grep -i passwordauthentication

   Releases before 3.19 ignore the sshd_config.d directory, which is why the main file changes too. If you use Match blocks, check that none of them turns password logins back on.
6. Patch images and templates, not just servers. Rebuild container images that run sshd, refresh golden images and cloud templates, and update provisioning scripts so new hosts start with password logins off.
7. Look for signs of a break-in. Alpine suggests searching /var/log/messages for "Accepted password for" on accounts that have no password, such as root, alpine or key-only users, and reviewing doas use, new users, new files and authorized_keys. GreyNoise lists files that attackers left behind:

   # Password logins in the system log
   grep "Accepted password for" /var/log/messages
   
   # Files and key tags seen in real SSHole intrusions
   ls -l /opt/py3/tac_agent.py /etc/init.d/tac-agent 2>/dev/null
   grep -rn -e SSHHOLE-HIT -e fleet-access /root/.ssh /home/*/.ssh 2>/dev/null
   grep -n "tac.vpnla.org" /etc/hosts

8. If you find anything, rebuild. Alpine's advice is to treat the system as compromised if you cannot rule out a login. Rebuild from a known-good image, replace host keys and authorized_keys, and rotate every secret the machine could reach, including cloud credentials, since attackers queried cloud metadata services.

One shortcut to avoid: do not lock key-only accounts as a quick fix. The researcher's timeline notes that when Alpine locked root in its Docker images in 2019, it also broke SSH key logins on sshd without PAM.

SSHole timeline: from fix to KEV in four days

Times are from GreyNoise's tracker. Four days from fix to KEV listing leaves no room for a monthly patch cycle.

What did attackers do after an SSHole login?

GreyNoise publishes a running summary of SSHole activity against its own sensors. As of 10 November 2026 at 02:40 UTC, it counted 18 successful exploitation chains from six attacker IP addresses. The activity it describes includes:

• checking for containers and querying AWS, Azure and Alibaba Cloud metadata services;
• trying to read /etc/shadow and root's SSH keys through doas;
• adding entries to authorized_keys under /root/.ssh and /home/alpine/.ssh, one tagged SSHHOLE-HIT;
• editing /etc/hosts and overwriting /etc/resolv.conf;
• installing a Python implant called TAC Agent, with an init script so it starts at boot, which polls tac.vpnla.org.

GreyNoise says the implant never enrolled with its server on the victims it watched, so it received no tasks. BleepingComputer reported that GreyNoise does not consider these attacks representative of all SSHole activity, so expect other attackers and other tools.

SSHole lands a week after the Tailscale SSH Tailworm fixes, and the lesson is the same: remote access is the first thing to patch. Teams that run their own VPS carry this work themselves, one of the trade-offs in our VPS, serverless and managed hosting comparison. Build it into the routine in our website maintenance cost guide, and see how to secure a web application for the wider checklist.

If you run a handful of Alpine servers or containers and want a second pair of eyes on SSH settings, images and patch routines, our web development team can help. Get in touch and tell us what you host and where.

SSHole FAQ

Is SSHole being exploited?

Yes. GreyNoise saw the first successful exploitation on 7 November 2026 at 00:46 UTC, about 40 hours after the fix was published, and counted 18 successful chains from six IP addresses by 02:40 UTC on 10 November. CISA added CVE-2026-123158 to its Known Exploited Vulnerabilities catalog on 9 November, with a 12 November due date for US federal agencies. A public exploit has been available since 5 November.

Does SSHole affect Ubuntu or Debian servers?

Not on the attack path described so far. The researcher says glibc systems that check passwords through PAM, such as Debian, Ubuntu and Fedora, are not affected. Debian's tracker still lists older openssh packages as vulnerable as of 10 November 2026, so install the update when it lands, but patch Alpine and other musl hosts first.

Is my Alpine Docker container vulnerable to SSHole?

Only if the container runs sshd. Alpine says Docker and other container users are not affected otherwise. Check your Dockerfiles for openssh-server and an sshd entrypoint. Images that do run sshd, such as SSH bastion, SFTP or CI images, need a rebuild on a patched Alpine base and a redeploy, because a running container never updates itself.

Why does ssh -V not show 10.6p2 after I patched Alpine?

Because Alpine backported the fix. Stable branches keep their OpenSSH base version and get a new package release instead, such as 10.0_p1-r11 on Alpine 3.22 or 10.3_p1-r2 on 3.24. Only edge moved to 10.6_p2-r0. Check the package version with apk info -v, compare it with Alpine's advisory, and remember to restart sshd after the upgrade.

Does PasswordAuthentication no fully protect against SSHole?

For this bug, yes. Alpine lists systems with PasswordAuthentication no as not affected, and musl's maintainer gives the same advice for hosts that cannot be upgraded right away. Confirm the effective value with sshd -T, check Match blocks that might turn passwords back on, and restart sshd after the change. Still install the fixed package, because settings can drift back over time.

Do I need to rotate SSH keys after SSHole?

Only if you find signs of a login or cannot rule one out. In that case, Alpine says to treat the system as compromised: rebuild it, replace host keys and authorized_keys, and rotate every credential the machine could read, including cloud keys. If the logs and the GreyNoise file checks are clean and the host is patched, updating and restarting sshd is enough.

Sources

• OpenSSH release notes: OpenSSH 10.6p2 (5 November 2026)
• OpenSSH portable: commit "avoid password authn bypass"
• Alpine Linux security advisory: openssh-server password authentication bypass (5 November 2026)
• sshhole.com: the researcher's write-up
• musl mailing list: Rich Felker on the OpenSSH password bypass (6 November 2026)
• CVE record: CVE-2026-123158
• CISA: four known exploited vulnerabilities added to the catalog (9 November 2026)
• CISA KEV catalog data feed (CVE-2026-123158 entry, due 12 November 2026)
• GreyNoise: SSHole (CVE-2026-123158) activity tracker
• BleepingComputer: Hackers exploit SSHole OpenSSH flaw to breach Linux systems (9 November 2026)
• Debian security tracker: CVE-2026-123158
• Ubuntu security: CVE-2026-123158
• Coolify discussion 12484: Alpine installer and password authentication (7 November 2026)