OpenSSH 'sshole' bug lets anyone log into passwordless accounts on Alpine Linux: patch CVE-2026-123158 now

The OpenSSH project shipped version 10.6p2 on November 5 to fix CVE-2026-123158, nicknamed "*sshole": on Linux systems built with the musl C library and running sshd without PAM — the default on Alpine Linux — an attacker who can reach the SSH port can log into an account that has no password simply by sending a very long password. Alpine published fixed packages the same day for every supported branch back to 3.16. MITRE rates the flaw 8.1 (High) on CVSS 3.1, according to OX Security and Cycode.

Why it matters: Alpine is the base of a huge share of Docker images and small cloud VMs, and musl also underpins embedded build systems. The bug is a simple logic error rather than memory corruption, so it is easy to reproduce, and the fix landed within about a day of the report — OpenSSH's maintainers now skip long embargoes because, as Cycode and OX relay, AI tools can rediscover a reported bug within hours. Defenders should assume working exploits will circulate quickly.

How the bypass works

Without PAM, OpenSSH verifies a password by hashing it with the C library's crypt() function and comparing the result with the stored hash in /etc/shadow. According to administrator.de and Tech Insider:

• On musl, crypt() rejects passwords longer than 256 bytes and returns the string * instead of a hash.
• Accounts that have no usable password — locked or key-only users — typically have * in their shadow password field.
• When the two * strings match, sshd treats the login as successful. One report gives a working password length of 257 to 1,024 bytes.

administrator.de says the behaviour grew out of several changes made between 2012 and 2016 and went unnoticed for roughly a decade. The issue was reported by Özgün Kültekin of Wakefield.

Are you affected?

OX Security and Cycode say a system is exposed only when all of these are true:

Two details raise the stakes. Alpine's official cloud images from 3.18.11 to 3.24.3 ship an alpine user with no password that can run doas as root, the researchers say, so a vulnerable VM can become a root compromise. Root itself is protected under the default PermitRootLogin prohibit-password.

Not affected, per the same reports: glibc-based distributions such as Debian, Ubuntu and Fedora; any sshd that authenticates through PAM; and Dropbear, which is OpenWrt's default SSH server. Tech Insider notes that musl-based OpenWrt, Buildroot and Yocto builds are in scope only if they ship OpenSSH configured as above.

On containers, OX says several popular Docker Hub SSH images — Gitea, Gogs, the Jenkins SSH agent, and linuxserver's openssh-server unless PASSWORD_ACCESS=true — disable password logins by default, but a small number were exposed under their documented setup. Images built on Alpine releases older than 3.16 were exploitable in the researchers' lab and will get no fix.

No exploitation in the wild has been reported so far; the only confirmed exploitation is the researchers' own lab testing.

Fixed versions

Upstream, the fix is OpenSSH 10.6p2. Other musl-based distributions and firmware vendors need to ship that release or a backport.

What to do now

1. Check exposure on each Alpine host or container running sshd (as root):

   sshd -T | grep -i -E 'passwordauthentication|usepam'

   If password authentication is off, or PAM is on, you are not exposed.

2. Update and restart:

   apk upgrade -U -a
   rc-service sshd restart

   Then rebuild and redeploy any container image whose openssh package is older than the version in the table above. Updating a running container without rebuilding the image will not survive a redeploy.

3. If you can't patch yet, set PasswordAuthentication no in sshd_config and restart sshd — after confirming key-based logins work, so you don't lock yourself out. On Alpine releases before 3.16 this is the only fix.

4. Look for compromise: search /var/log/messages for Accepted password entries for accounts that have no password. The researchers say any match should be treated as a compromised system.

Who should care most: anyone with Alpine-based VMs from the official cloud images, homegrown SSH-enabled containers, bastion or Git-over-SSH containers built on Alpine, and embedded devices that ship OpenSSH on musl. If your SSH servers already require keys only, this one passes you by — but it is a good reason to make that the rule everywhere.