Vulnerabilities

On November 5, 2026 the OpenSSH project released 10.6p2, a point release with one security change: sshd now refuses a password check that could let anyone log in to an account that has no password at all. Alpine Linux published fixed packages the same day for every branch back to 3.16. The trigger is a password between 257 and 1,024 bytes long, sent once over a normal SSH connection.

You are affected if sshd is built against musl libc (Alpine, plus some OpenWrt, Buildroot and Yocto builds), runs without PAM (Pluggable Authentication Modules), still allows password logins, and has both an account whose password field is * and another account with a real SHA-256 or SHA-512 hash. Alpine's standard openssh-server package is built without PAM and password logins are on by default, so a typical Alpine host only needs someone to have run passwd once. glibc distributions such as Debian, Ubuntu and RHEL are not affected, and neither are Dropbear or OpenBSD.

How it works

Without PAM, sshd checks a password itself. It takes the hash stored in /etc/shadow, uses it as the salt for the C library's crypt() function, hashes the submitted password, and compares the result with the stored string. If the two strings match, the user is in.

An account with * in the password field has no hash, so it has no usable salt. Since 2016, when OpenSSH fixed a timing leak that let attackers enumerate usernames (CVE-2016-6210), sshd borrows a salt from another local account in that case, so that checks for real and fake accounts take the same time. That is why the attack needs a second account with a $5$ (SHA-256) or $6$ (SHA-512) hash: it supplies the algorithm and salt.

musl adds the second half. POSIX says crypt() returns NULL when it fails, but since August 2012 musl has returned the string * instead. musl's SHA-256 and SHA-512 code also rejects passwords longer than 256 bytes. Send a 257-byte password, crypt() fails, returns *, sshd compares * with the stored *, and authentication succeeds. sshd itself caps passwords at 1,024 bytes, which sets the upper end of the working range.

Accounts locked with ! are not exposed, because ! never equals the failure string. Alpine's own history explains why * is common there: after CVE-2019-5021 (Docker images shipped with an empty root password), Alpine locked root with !, which also blocked key logins, and later switched root to * so keys work while passwords stay refused. Key-only service users and directory accounts without shadow entries often carry * as well.

OpenSSH treats the bug as a musl problem: its release notes say the root cause is "outside sshd" but exploitable through it. The 10.6p2 change is a workaround that refuses the comparison when the stored field is too short to be a real hash. The researcher's repository says every release since 7.3p1, the version that added the borrowed salt, is affected, and includes a patch for older builds.

Who found it and what we know about abuse

Özgün Kültekin of Wakefield reported the bug and published the analysis under the name "sshhole". He describes testing about 17,600 logins across glibc and musl builds with and without PAM; only musl without PAM accepted logins the others refused. The OpenSSH commit, titled "avoid password authn bypass", landed on the V_10_6 branch on November 4, a day before release.

No source reports exploitation in the wild so far, and no CVE ID had been assigned when Alpine published its advisory. The bar is very low, though: one connection, no prior access and a password made of 257 repeated characters. Expect scanners to pick it up quickly.

The worst case is Alpine's official cloud images. Images built with tiny-cloud from 3.18.11 through 3.24.3 create an alpine user with * in the password field and passwordless doas, the Alpine equivalent of sudo. Alpine says these are safe on first boot and become exploitable as soon as any $6$ hash exists on the machine. After that, the bypass gives an attacker a shell as alpine and then root with one doas command.

What to do

1. Upgrade and restart. On Alpine run apk upgrade -U -a, then rc-service sshd restart. The running daemon keeps the old code until it restarts. Fixed openssh packages:

New cloud images from 3.21.10, 3.22.8, 3.23.8 and 3.24.4 include the fix. If you build OpenSSH from source against musl, for an appliance or a Yocto or Buildroot image, move to 10.6p2. OpenWrt and embedded vendors had not published their own advisories at the time of writing, so check builds that ship OpenSSH rather than Dropbear yourself.

2. If you cannot patch today, turn off password logins. Confirm key login works and keep a session open first. Alpine's advisory uses a drop-in file plus an edit to the main config, because drop-ins are only read from 3.19 onward: write PasswordAuthentication no to /etc/ssh/sshd_config.d/00-no-passwords.conf, set the same line at the top of /etc/ssh/sshd_config, run sshd -t && rc-service sshd restart, and confirm sshd -T | grep -i passwordauthentication prints passwordauthentication no. Switching to the openssh-server-pam package with UsePAM yes also closes the path.

3. Find the exposed accounts. awk -F: '$2=="*"{print $1}' /etc/shadow lists accounts with *, and grep -c ':\$[56]\

   #39; /etc/shadow tells you whether a salt source exists. The researcher's check.sh at github.com/oz9un/sshole runs the full set of conditions.

4. To check whether you were already hit, search /var/log/messages for sshd lines reading Accepted password for followed by an account from step 3, such as root, alpine or a key-only service user. Any such line is a strong indicator, since those accounts cannot have a valid password. Standard sshd logging does not record password length, so the log line will look like any other password login. Then review doas use, new users in /etc/passwd, recently changed files and every ~/.ssh/authorized_keys. If logs are missing or you cannot rule out a login, Alpine advises treating the machine as compromised.

5. After a confirmed login, rebuild from a fixed image, rotate the host keys and any credentials, tokens or keys the machine held, and remove authorized keys you did not add.

Password logins on servers

Every condition in this chain was a reasonable default on its own: no PAM to keep the image small, a * for key-only users, one admin account with a password for the console. Together they let an attacker reach accounts that were never meant to accept a password. Servers that only accept keys were not exposed at all, which makes PasswordAuthentication no worth enforcing as a baseline on every image, with exceptions documented rather than inherited. Containers that do not run sshd are unaffected.

If you want a second look at how your Linux images and SSH exposure are configured, our safeguarding and hardening team audits baselines like this one, and network penetration testing checks what is actually reachable from outside. Open the chat and ask Yaali, our AI agent, who will pass your question to an engineer.

---

Sources: https://www.openssh.org/releasenotes.html, https://alpinelinux.org/posts/2026-11-05-openssh-password-authentication-bypass/, https://sshhole.com/, https://github.com/oz9un/sshole, https://github.com/openssh/openssh-portable/commits/V_10_6, https://threatlandscape.io/blog/openssh-musl-linux-arbitrary-long-passwords-locked-accounts, https://pbxscience.com/openssh-releases-emergency-10-6p2-fix-for-long-password-authentication-bypass-on-alpine-linux/, https://thehackernews.com/2026/11/openssh-issues-emergency-fix-for-flaw.html