CVE-2026-123158

How it works. Per Alpine, when sshd is built without PAM it checks a password by hashing the attempt with crypt() and comparing the result to the stored password field. "musl's crypt() returns the string * as an error indicator when the key is over 256 bytes long. * is also exactly what the stored field contains for every account with no password, so the 'hash' matches and the login succeeds." Alpine says the attack sends "a very long password (257 to 1024 bytes)" and "works every time." OpenSSH says "We consider the root cause of this bug to be outside sshd, but it is exploitable via sshd and can be avoided there," and credits Özgün Kültekin of Wakefield.

Who is affected. Per Alpine, all of these must be true.

• You run the Alpine openssh-server package, which is built without PAM, or openssh-server-pam with UsePAM no.
• PasswordAuthentication is yes, "the OpenSSH default, unless you changed it."
• An account has * as its password field. That includes root (shipped as root:* since about Alpine 3.16), key-only users created without a password, users from a directory service through musl-nscd, and the alpine user in the official cloud images.
• At least one local account has a $5$ or $6$ password hash.

Who is not affected, per Alpine. Containers that do not run sshd, systems with PasswordAuthentication no, openssh-server-pam with UsePAM yes, locked accounts (! in the password field), systems where no account has a $-style hash, and cloud images set up through cloud-init, which writes PasswordAuthentication no. NVD's description limits the bug to Linux with musl and no PAM; it does not name glibc distributions such as Ubuntu, Debian or RHEL.

1. Check that sshd runs, and how it was built. On Alpine, see whether openssh-server or openssh-server-pam is installed and, for the PAM build, whether UsePAM is yes.
2. Check that the running sshd is fixed. Compare the openssh package to Alpine's fixed versions below, then confirm sshd was restarted. Alpine says "Upgrading the package alone does not replace the running daemon."
3. Check password authentication. Run sshd -T | grep -i passwordauthentication, including any Match blocks. Alpine's safe result is passwordauthentication no.
4. Check the accounts. In /etc/shadow, list accounts with * and any with a $5$ or $6$ hash. The bypass needs both.
5. Check the path to root. Run sshd -T | grep -i permitrootlogin. If it is yes, root is reachable directly. Otherwise check whether any * account has doas or other ways to become root.
6. Check Alpine cloud images separately. Alpine says the official 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. They become exploitable as soon as any $6$ hash exists on the machine." Images built from 3.21.10, 3.22.8, 3.23.8, 3.24.4 and later include the fixed package.

Fixed versions. Upstream, OpenSSH 10.6p2 (released November 5, 2026). Alpine's fixed openssh packages are 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 and 3.16 9.0_p1-r6. Alpine 3.21.10, 3.22.8, 3.23.8 and 3.24.4 include the fix.

Exploitation, as reported. Previdian's record for this CVE says its sensors "have observed 8 exploitation attempts, 1 unique attacker IP, and 1 country," first seen November 6, with confidence "Confirmed." Previdian notes confidence "does not mean the attempt succeeded." OpenSSH, Alpine and CISA have not reported exploitation.

These come from Alpine's advisory. Each works only under the condition at the end of its line.

• Exploitation. Turn off password logins with PasswordAuthentication no and restart sshd. Alpine says either this or the update "closes the hole," and gives exact commands, including a drop-in file that Alpine reads from 3.19 onward. This only helps if sshd -T then prints passwordauthentication no, and only after you confirm key login works before closing your current session.
• Exploitation. Lock accounts that never need to log in by setting ! instead of *. Alpine says locked accounts "cannot log in with a password or a key," so this only suits accounts that don't need key logins either.
• Execution. Keep PermitRootLogin at the default prohibit-password and review doas rules for accounts with * passwords. Alpine says the default protects root but "does not help if another account that can log in is able to become root." This only helps if no reachable account can escalate, which is exactly what the cloud images' alpine user can do.

Upgrading OpenSSH, then restarting sshd, is the fix.

Alpine: "Look in /var/log/messages for sshd lines reading Accepted password for an account that has no password (alpine, root, or any key-only user)." OpenSSH publishes no indicators.

If you patched late. Upgrading does not undo a login that already happened. Alpine says to "Review doas use and recently created users, files and authorized keys on exposed machines. If you cannot rule out a login, treat the machine as compromised."

Am I exposed to CVE-2026-123158?

Yes, if sshd runs a build without PAM on musl (Alpine's openssh-server, or openssh-server-pam with UsePAM no), password logins are on, an account has * as its password field, and another account has a $5$ or $6$ hash.

Is CVE-2026-123158 being exploited?

Previdian reports 8 exploitation attempts from one attacker IP, first seen November 6, and says that does not mean the attempts succeeded. OpenSSH, Alpine and CISA have not reported exploitation, and it is not on CISA KEV as of November 6, 2026.

Can an attacker log in as root?

Not with OpenSSH's default settings, per Alpine, unless PermitRootLogin yes is set. An account that can become root, for example through doas, is another way in.

Does this affect Ubuntu, Debian or RHEL?

NVD limits the bug to Linux with musl libc and no PAM, and names Alpine as the example. It does not name glibc distributions.

I only run Alpine in Docker containers. Am I exposed?

Not if the container doesn't run sshd, per Alpine.

Is upgrading the package enough?

No. Restart sshd afterward. Alpine says upgrading alone does not replace the running daemon.

Nov 6, 2026. First published. Previdian reports exploitation attempts; not on CISA KEV.

• OpenSSH 10.6p2 release notes (Nov 5, 2026)
• Alpine Linux advisory, openssh-server password authentication bypass (Nov 5, 2026)
• NIST NVD: CVE-2026-123158 (MITRE's CNA record; checked Nov 6) and fix commit
• Previdian, CVE-2026-123158 exploitation record (third-party sensor report)
• CISA Known Exploited Vulnerabilities catalog (checked Nov 6)