The OpenSSH Flaw "*sshole": Only Linux Systems Like Alpine Are Affected. How to Check and What to Do

On November 5, 2026, OpenSSH shipped an emergency security release (10.6p2). It fixes a flaw (CVE-2026-123158, nicknamed “*sshole”) that lets someone log in over SSH to an account that has no password, just by entering a very long password (OpenSSH release notes).

The Japanese headlines said “an OpenSSH vulnerability,” but the range of affected systems is narrow. This article sets out the conditions, how to check, and what to do, from primary sources. The information is current as of November 6, 2026.

Much of what circulates in Japanese differs from the original text. We read the primary sources ourselves, but we recommend that you check the originals too.

Key points

• The affected systems are Linux systems where sshd runs on musl libc without PAM. Alpine Linux is an example. OpenSSH’s developer writes that the flaw does not exist on non-Linux systems, on Linux with glibc, or on Linux that uses PAM for password authentication (developer’s announcement).
• Debian, Ubuntu, Fedora and RHEL use glibc, so they are not affected.
• It works only when all four conditions hold (table below).
• The fix is OpenSSH 10.6p2. Alpine has also shipped fixed packages for each branch.
• If you cannot update, turn off password authentication. The developer says to do it immediately.
• No real-world attacks had been reported as of November 5. But public reproduction labs already exist (referenced in the CVE record).

The headline, and the primary sources

The conditions

Ethiack’s write-up says all four of the following are required (Ethiack).

How it works

According to Ethiack’s write-up (Ethiack):

1. When musl libc’s crypt() receives a password that is too long (over 256 bytes), it returns “*” as an error marker. glibc returns NULL
2. On Alpine, the field for an account with no password is also “*”
3. sshd compares the returned “” with the stored “,” finds them equal, and accepts the login
4. Because “*” has no salt, sshd borrows the salt from another account’s hash. That is why condition 4 is needed

The fix rejects a stored hash shorter than four characters. The commit defines a minimum length of 4 (commit).

Can it reach root?

Ethiack’s write-up says the following (Ethiack).

• On Alpine, root has been “*” since about 3.16, but the default PermitRootLogin prohibit-password blocks password login. Unless you changed it, it does not reach root
• Alpine’s cloud images (3.18.11 to 3.24.3) have an alpine user that is “*” and passwordless doas. If another account has a $6$ hash, root is reachable from there
• Docker containers are affected only if they run sshd with password login
• OpenWrt and Buildroot images may also be affected if the conditions are met

Checking whether you are affected

On your own server, check in this order. Some need root.

ldd --version 2>&1 | head -1
sshd -T | grep -i -E "passwordauthentication|usepam"
grep -E '^[^:]+:\*:' /etc/shadow | cut -d: -f1
grep -E '^[^:]+:\$[56]\$' /etc/shadow | cut -d: -f1

The first line shows whether it is musl (the output says “musl”). The second shows whether password authentication is on and the PAM setting (a build without PAM may not print a usepam line). The third lists accounts that are “*.” The fourth lists accounts with a $5$ or $6$ hash.

If both the third and fourth lines list accounts, the first line says musl, and the second shows password authentication enabled, you meet the conditions.

Fixed versions

The fixed OpenSSH version is 10.6p2 (November 5, 2026; release notes).

On Alpine’s tracking page, the fixed versions are as follows (Alpine).

3.18 and earlier are not listed on that tracking page. Ethiack’s write-up also has a per-branch table, but it is off by one branch compared with Alpine’s page. This article follows Alpine’s page.

Alpine’s fixed packages keep older version numbers. A scanner that checks only the version number can show a patched system as vulnerable (Ethiack).

What to do now

1. Update and restart sshd

On Alpine, do the following. Until you restart, the running sshd stays on the old code.

apk update && apk upgrade
rc-service sshd restart

2. If you cannot update right away

Turn off password authentication. OpenSSH’s developer writes to set PasswordAuthentication no, or to disable SSH on these systems, immediately (developer’s announcement). Confirm that you can log in with a public key before you switch.

3. Unaffected environments

Environments that use glibc, such as Debian and Ubuntu, and environments that use PAM for password authentication, are not affected by this flaw. No special action is needed.

How it was reported

The reporter was Özgün Kültekin of Wakefield (release notes). OpenSSH learned of the problem the day before release. It shipped the fix the next day, with no embargo.

The developer, Damien Miller, writes that he now considers long embargo periods a dangerous practice. The reason is that he has seen AI agents rediscover the same bug within hours (developer’s announcement). The release notes also say bugs found by AI tools are often found independently by other researchers, so OpenSSH will make more frequent releases for now (release notes).

What we could not confirm

• Real-world attacks had not been reported as of November 5 (Ethiack). The situation since then is not confirmed
• “About ten years” comes from Ethiack’s write-up. OpenSSH’s announcement does not say it
• The difference between “256 bytes” and “257 bytes”
• Whether the conditions are actually met on OpenWrt, Buildroot and container images
• Alpine’s tracking page has no description text

Related articles

• A Severity 9.8 Linux Kernel Flaw: What the AI-Built Attack Needs, and Where Each Distribution Stands: the Linux kernel flaw from the same week, and where each distribution stands
• As Breaches Mount in Japan, What Leaders Should Decide First: Zero Trust and Security in the Age of AI: a way for executives to think about security as breaches mount

If you need help checking your servers’ configuration or planning updates, please contact us.