SSHole (CVE-2026-123158): SSH Password Bypass on Alpine Linux

Published on November 13, 2026

CVE-2026-123158 — OpenSSH sshd, musl systems without PAM. The flaw lets an attacker log in over SSH without knowing the password. It is being exploited: CISA added it to its Known Exploited Vulnerabilities (KEV) catalog on November 9, 2026. Debian, Ubuntu and AlmaLinux VPS are not affected. Do check your Alpine machines and containers that expose sshd.

The bug in two sentences

When built without PAM, sshd checks a password by hashing it with the C library’s crypt() function and comparing the result with the field stored in /etc/shadow. With musl, crypt() returns * when the password is longer than 256 bytes: that is exactly what the field holds for accounts with no password, so the login succeeds. Affected versions:

OpenSSH before 10.6p2, on Linux, built with musl and without PAM;
Alpine Linux, every branch from 3.16 to 3.24 plus edge, according to the Alpine advisory.

The fix shipped on November 5, 2026: OpenSSH 10.6p2, and fixed packages for every Alpine branch. The score published by NVD and cve.org is 8.1 (high attack complexity). Red Hat gives a preliminary 9.8. Ubuntu rates it high priority.

GreyNoise saw a first successful exploitation on November 7, 2026, two days after the fix and a public exploit came out. The recorded sessions go from reconnaissance to reading /etc/shadow and creating a server_manager account with a passwordless doas rule.

Sizing your exposure

Per the Alpine advisory, a machine is exposed when all of the following hold:

sshd comes from the openssh-server package (built without PAM), or from openssh-server-pam with UsePAM no;
PasswordAuthentication is yes, the OpenSSH default;
an account has * as its password field: root in the base image, a key-only user, a directory-service user;
at least one other local account has a $5$ or $6$ password hash.

The attacker needs the name of the target account. root stays protected by the default PermitRootLogin prohibit-password, unless another reachable account can become root, for instance through doas.

Profile	Exposure	Action
Debian, Ubuntu, AlmaLinux, Rocky Linux, RHEL VPS (system sshd)	Not affected	Nothing to do on the host
Alpine running sshd with `PasswordAuthentication yes`, reachable from the Internet	Critical	Update today and restart sshd
Alpine container running sshd with its port published	Critical	Rebuild the image with the fixed package; if you can’t, turn passwords off
Alpine tiny-cloud image, 3.18.11 to 3.24.3	Critical once any password is set	Update or turn passwords off on every instance
Alpine with `PasswordAuthentication no`, or `openssh-server-pam` with `UsePAM yes`	Not affected	Update at your next maintenance window
Alpine container without sshd	Not affected	Nothing to do
Embedded device on musl without PAM (Yocto images, for example)	Possible	Ask the vendor

The official tiny-cloud images (qcow2, VHD, AMI) ship an alpine user with no password and passwordless doas. They are safe on first boot, and become exploitable as soon as a password hash shows up on the machine, such as a console password set by the admin.

Debian, Ubuntu, AlmaLinux VPS: the host is not exposed

Ubuntu states that its OpenSSH is linked against glibc and uses PAM, so it is not vulnerable on any release. Red Hat says its products are not affected. Debian rates the flaw “unimportant” for its package and only carries the fix in unstable and forky. Your VPS’s own sshd needs no action. What you should check are the Alpine containers running on it.

# Running containers: name, image, published ports
docker ps --format 'table {{.Names}}\t{{.Image}}\t{{.Ports}}'

# For a container publishing an SSH port: distribution and whether sshd runs
docker exec <container> cat /etc/alpine-release
docker top <container> | grep sshd

A container that answers with an Alpine version number and runs sshd falls under the next section. The same goes for a Kubernetes pod built on an Alpine image that starts sshd.

Updating Alpine Linux

The fix is an update of the openssh package, followed by an sshd restart. Updating alone does not replace the daemon that is already running.

Branch	Fixed `openssh` package
edge	`10.6_p2-r0`
3.24	`10.3_p1-r2`
3.23	`10.2_p1-r1`
3.22	`10.0_p1-r11`
3.21	`9.9_p2-r1`
3.20	`9.7_p1-r6`
3.19	`9.6_p1-r3`
3.18	`9.3_p2-r4`
3.17	`9.1_p1-r7`
3.16	`9.0_p1-r6`

Point releases 3.21.10, 3.22.8, 3.23.8 and 3.24.4 include the fixed package. Alpine also published packages for branches that no longer get regular updates, all the way back to 3.16.

# Alpine: install the fix, then restart sshd
apk upgrade -U -a
rc-service sshd restart

# Check the installed version
apk list -I | grep openssh

Docker containers

If you own the image, rebuild it on an Alpine release that includes the fix (3.21.10, 3.22.8, 3.23.8, 3.24.4 or later), then recreate the container.

# Rebuild, pulling the latest base image
docker build --pull --no-cache -t <image> .

In the meantime, you can patch a running container:

docker exec <container> apk upgrade -U -a
docker restart <container>

That fix is lost the next time the container is recreated: only a rebuilt image lasts. For a third-party image, wait for the publisher’s fixed release and apply the mitigation below until then.

Mitigation until you can patch

Alpine recommends turning password authentication off. Before you start, make sure SSH key login works, and keep your current session open until you have tested a new login. Run as root:

# Drop-in configuration file (read by Alpine from 3.19 onward)
mkdir -p /etc/ssh/sshd_config.d
echo 'PasswordAuthentication no' > /etc/ssh/sshd_config.d/00-no-passwords.conf

# Flip every PasswordAuthentication line to no, add one at the top, keep the original as .bak
sed -i.bak -e '1i PasswordAuthentication no' \
  -e 's/^\(\s*PasswordAuthentication[^y#]*\)yes/\1no/i' \
  /etc/ssh/sshd_config

# Validate the configuration and restart sshd
sshd -t && rc-service sshd restart

The sed command also changes lines inside a Match block.

Verifying the mitigation

sshd -T | grep -i passwordauthentication

Expected: passwordauthentication no. After an update, compare the output of apk list -I | grep openssh with the table entry for your branch.

Looking for traces

Exploitation has been seen since November 7. On an exposed Alpine machine, look for password logins on accounts that have no password:

# Logins accepted by password
grep 'Accepted password for' /var/log/messages

# Accounts with no password (* field)
awk -F: '$2 == "*" {print $1}' /etc/shadow

An Accepted password for line on one of those accounts (root, alpine, a key-only user) means an intrusion. Also review doas use and recently created accounts, files and authorized_keys entries. A server_manager account you did not create is an indicator reported by GreyNoise. If you cannot rule out a login, treat the machine as compromised.

Rolling back the mitigation

Once the fixed package is installed, if you need passwords back:

rm /etc/ssh/sshd_config.d/00-no-passwords.conf
cp /etc/ssh/sshd_config.bak /etc/ssh/sshd_config
sshd -t && rc-service sshd restart

What next?

Key-only login remains the best setup for an exposed server: keep PasswordAuthentication no even after the update. For another recent OpenSSH flaw, read regreSSHion (CVE-2024-6387). For any technical question, open a ticket from your OnetSolutions customer area.

Overview

Product news

Web hosting

Tips & comparisons

Payment

Security advisories

SSHole (CVE-2026-123158): SSH Password Bypass on Alpine Linux

The bug in two sentences

Sizing your exposure

Debian, Ubuntu, AlmaLinux VPS: the host is not exposed

Updating Alpine Linux

Docker containers

Mitigation until you can patch

Verifying the mitigation

Looking for traces

Rolling back the mitigation

What next?