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

Many accounts on a Linux server are not supposed to have a password at all: service users, accounts that log in only with SSH keys, the default cloud user. On Alpine Linux those accounts could be opened with a password nobody ever set. The bug is old, but it was published on 5 November 2026 and attackers moved on it the same day.

How does the OpenSSH login bypass work?

The bypass comes from two reasonable decisions that interact badly.

First, an account without a usable password has a * in the password field of /etc/shadow. Since 2016, OpenSSH still hashes the submitted password for such accounts, using another account’s settings. This keeps the response time the same for every username, so attackers cannot tell real accounts from fake ones by timing.

Second, the crypt() function in the musl C library refuses SHA-256 and SHA-512 passwords longer than 256 bytes and returns * when it fails. That error value is exactly what the locked account stores. When sshd compares the two, they match, and the login goes through.

In short: send a password of more than 256 characters to a * account on a musl system, and sshd lets you in.

Which systems are affected by CVE-2026-123158?

A server has to meet all of these conditions:

• It runs OpenSSH older than 10.6p2 on a system that uses musl instead of glibc.
• sshd checks passwords without PAM. This is how Alpine’s standard openssh-server package is built.
• Password authentication is enabled, which is the OpenSSH default.
• At least one account has * as its password hash, and at least one other account has a real password hash.

Systems to check:

Root on Alpine has shipped with * since around version 3.16. The default PermitRootLogin setting blocks password logins for root, unless someone changed it. The bigger risk is indirect. On the official Alpine cloud images, the default alpine user has passwordless doas, so a login as alpine turns into root with one command.

Is CVE-2026-123158 being exploited?

Yes. The first attempt was seen less than nine hours after the CVE was published, and attackers got root on an Alpine test server. They used oversized passwords, then ran simple reconnaissance commands such as id, uname and hostname in non-interactive SSH sessions. Exploit code is also circulating in public repositories. Some of it is unverified and may itself contain malware, so do not run it on systems you care about.

How do I fix it on Alpine Linux?

1. Update OpenSSH

Alpine released patched packages for branches 3.16 through edge on the day of disclosure:

apk update
apk upgrade openssh
apk info -v | grep openssh

2. Restart sshd

Upgrading the package does not replace the sshd process that is already running. Restart it:

rc-service sshd restart

Keep your current SSH session open and test a new login in a second window before you disconnect.

3. Turn off password logins

If your users log in with SSH keys, which they should, disable passwords completely. This blocks the bypass even on a system you have not updated yet:

# /etc/ssh/sshd_config
PasswordAuthentication no
KbdInteractiveAuthentication no
PermitRootLogin prohibit-password

sshd -t && rc-service sshd restart
sshd -T | grep -E 'passwordauthentication|permitrootlogin'

4. Find the accounts that were exposed

awk -F: '$2=="*" {print $1}' /etc/shadow

Every name in this list could have been opened before the fix. Pay special attention to users that have a login shell and to anyone listed in /etc/doas.conf or /etc/doas.d/.

How do I check if my server was already accessed?

On Alpine, sshd writes to /var/log/messages by default. Look for successful password logins:

grep "Accepted password for" /var/log/messages*

A password login for alpine, root or any key-only user is a red flag. Then check:

• new or unknown users in /etc/passwd
• changes to ~/.ssh/authorized_keys for every user, including root
• edits to /etc/doas.conf
• unknown processes, cron jobs and outgoing connections (ps aux, crontab -l, netstat -tnp)

If you find a bypass login, assume the server is compromised. Back up the data you need, rebuild from a clean image, and replace every SSH key, password and API token that was stored on it.

Containers and embedded devices

Most Alpine-based application containers do not run an SSH server, so they are not exposed. Containers that do run sshd, often used as jump hosts or for remote development, should be rebuilt from an updated base image and redeployed. Routers and appliances built on OpenWrt, Buildroot or Yocto depend on the vendor shipping new firmware. Until then, keep their SSH port off the public internet.

The lesson for every Linux server

This bug only works against SSH password logins. A server that accepts keys only was never at risk, whatever library it runs on. Key-only SSH, a firewall that limits who can reach port 22, and automatic security updates would have made CVE-2026-123158 a non-event. Our Linux VPS security checklist covers each of those settings step by step.

If you want a fresh Alpine, Debian or Ubuntu server to try these settings on, our KVM VPS plans give you full root access and are ready in minutes.