CVE-2026-123158 (sshole): Alpine password bypass

On an Alpine Linux server that accepts SSH passwords, a password between 257 and 1024 characters long can log in to an account that has no password at all. CVE-2026-123158, nicknamed sshole, is in OpenSSH's sshd on Linux systems that use musl libc without PAM. OpenSSH 10.6p2 fixes it, and Alpine's patched packages are openssh 10.3_p1-r2 on 3.24, 10.2_p1-r1 on 3.23 and 10.0_p1-r11 on 3.22.

It is already being used. GreyNoise saw the first successful exploitation on 7 November 2026, two days after the fix, and CISA gave US federal agencies until 12 November to act. Alpine's advisory puts it bluntly: an attacker who can reach the SSH port "can log in without knowing any password", in one connection that "works every time". Alpine's own cloud images can be exposed too, as the root section below explains.

Check an Alpine server for CVE-2026-123158

Four read-only commands answer the question. Run them as root on each Alpine host that runs sshd:

# 1. Installed openssh-server version; compare it with the table below
grep -A1 '^P:openssh-server$' /lib/apk/db/installed

# 2. Is password login on? (from Alpine's advisory)
sshd -T | grep -i passwordauthentication

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

# 4. Accounts with a $5$ or $6$ hash: one of them makes every "*" account reachable
awk -F: '$2 ~ /^\$[56]\$/ {print $1}' /etc/shadow

A host is exposed when all four line up: an older openssh-server, passwordauthentication yes, at least one * account, and at least one $5$ or $6$ account.

The fixed versions come from Alpine's advisory. The live package indexes for edge and 3.21 to 3.24 list the same versions:

Two setups are safe as they stand. Alpine's openssh-server-pam package with UsePAM yes isn't affected, and neither is a container that doesn't run sshd at all.

How a 257-character password matches a missing one

Without PAM, sshd checks a password itself. It hashes the attempt with the C library's crypt() and compares the result with the account's stored password field. For a stored field too short to hold a salt, such as *, sshd borrows the salt of another account. That is why the attack needs one account with a real $5$ or $6$ hash.

Then musl takes over. Its SHA-512 crypt source sets KEY_MAX to 256 and rejects any longer key, and the file's own header states the rule: "on error "*" is returned." The SHA-256 version has the same limit and the same error value.

So a 257-byte password fails to hash and comes back as *. That string is exactly what the stored field holds for every account without a password, and the comparison passes. Alpine's advisory gives the working range as 257 to 1024 bytes.

OpenSSH's maintainers don't see this as their bug. The OpenSSH 10.6p2 release notes call it "a critical security workaround": "We consider the root cause of this bug to be outside sshd, but it is exploitable via sshd and can be avoided there." The fix in sshd refuses to match a stored password field shorter than four characters, which rules out * whatever crypt() returns.

Damien Miller's release announcement also draws the boundary of who can ignore it:

“This vulnerability does not exist on non-Linux systems, Linux/glibc systems and Linux systems that use PAM for password authentication.”

— Damien Miller, OpenSSH

Is root reachable through sshole?

Directly, only if you allowed it. Alpine's base image ships root as root:*, and the 3.24.4 minirootfs released on 5 November still has that line. OpenSSH's default PermitRootLogin prohibit-password, the commented default in the sshd_config Alpine ships, blocks password logins for root. Alpine is clear that "root is only reachable if PermitRootLogin yes is set."

Indirectly, root is one step away on many machines. Any * account that can become root through doas is enough. Alpine's tiny-cloud images from 3.18.11 through 3.24.3 ship an alpine user with a * password field and passwordless doas. They are safe on first boot. Once anyone sets a $6$ password, for a console login or a user added through user-data, an attacker gets a shell as alpine and then root.

Key-only users are the other common victims. Alpine names any user added with adduser and no password, and directory-service users that come through musl-nscd. Images configured by cloud-init are the exception, because cloud-init writes PasswordAuthentication no.

Who is exploiting CVE-2026-123158?

Exploitation was fast and narrow. GreyNoise's tracking page lays out the timeline:

• 5 November 2026, 09:01 UTC: OpenSSH 10.6p2 released.

• 5 November, 13:16 UTC: the first public exploit appeared on GitHub, about four hours later.

• 7 November, 00:46 UTC: the first successful exploitation GreyNoise observed.

• 9 November: CISA added CVE-2026-123158 to its Known Exploited Vulnerabilities catalog.

Most of the traffic is ordinary scanning. Since 5 November GreyNoise counted 47.9 million SYN scans of port 22 but only five possible exploitation attempts. It confirmed 33 post-exploitation actions from nine attacker addresses. One cluster it tracks dropped a Python runtime and a "TAC Agent", talked to a command-and-control host at tac.vpnla.org, and set up a startup service to persist.

CISA's catalog entry sets 12 November 2026 as the due date and requires forensic triage. I'd apply that second part everywhere, not just at US agencies: a patched server that was open last week may already have someone on it.

NVD's record scores it 8.1 (High), and CISA's assessment there marks exploitation as active and the technical impact as total.

Fix CVE-2026-123158 and look for a break-in

To fix CVE-2026-123158, upgrade, then restart sshd. Upgrading the package alone does not restart sshd, so the old binary keeps answering until you do:

apk upgrade -U -a
rc-service sshd restart

If you can't upgrade today, turn password logins off. Make sure key login works first and keep your current session open. This is a shortened form of Alpine's drop-in, which needs Alpine 3.19 or later; on older releases, use the full sed command in Alpine's advisory:

mkdir -p /etc/ssh/sshd_config.d
echo 'PasswordAuthentication no' > /etc/ssh/sshd_config.d/00-no-passwords.conf
sshd -t && rc-service sshd restart
sshd -T | grep -i passwordauthentication

The last command should print passwordauthentication no.

Don't change * to ! on key-only accounts as a quick fix. Alpine notes that locked accounts can't log in with a password or a key, so you would lock those users out.

Then look for a login that shouldn't exist. Alpine's advice is to search /var/log/messages for an "Accepted password for" line naming an account that has no password, such as alpine, root or a key-only user:

grep 'Accepted password for' /var/log/messages

Review doas use, new users, new files and authorized_keys on any exposed machine. Alpine's rule is the right one: "If you cannot rule out a login, treat the machine as compromised."

What the Alpine update doesn't cover

Alpine's packages fix CVE-2026-123158 on Alpine only. The researchers who found the bug list other musl-based systems without PAM: sshhole.com names OpenWrt, Buildroot, Yocto "and a lot of the docker images you've pulled". Each of those needs its own updated sshd, and a container image with sshd baked in needs rebuilding, not just restarting.

Support status doesn't help either. Alpine 3.21 reached end of support on 1 November 2026, yet Alpine published fixed packages back to 3.16. I'd take that as a hint to move off unsupported releases while the fixes are still being backported for you.

The root cause also stays in musl. OpenSSH avoided it in sshd, but any other program that compares crypt() output against a stored field could hit the same *. If you run custom login code on musl, I'd check it for the same comparison.

This isn't the first time a C library turned a small check into root. Looney Tunables in glibc did it locally in 2023, and OpenSSH had its own remote code execution flaw, CVE-2023-38408, that year.

The quickest win this week is the one Damien Miller asked for: on every musl host you can't patch today, turn password authentication off.