OpenSSH Password Bypass on Alpine and musl Linux: Are You Affected?

Where things stand on 10 November 2026

CISA added CVE-2026-123158 to its Known Exploited Vulnerabilities (KEV) catalogue on 9 November 2026, citing evidence of active exploitation. The catalogue entry is titled 'OpenBSD OpenSSH Unexpected Status Code or Return Value Vulnerability'. That title is easy to misread. It names the upstream project, not the operating system. The flaw is in how sshd behaves on certain Linux builds, and OpenBSD is not among the affected systems.

The OpenSSH project fixed the problem in version 10.6p2, released on 5 November 2026. Alpine Linux has published fixed packages for its supported branches. The weakness is a password authentication bypass: on an affected build, a very long password can be accepted for an account that should not accept a password at all. NVD and MITRE score it CVSS 3.1 8.1 (High), recorded as CWE-394.

Details are still developing. The exploitation evidence is solid enough to act on, but the public numbers come from a small number of sensors and honeypots, and they say little about how many real servers have been entered. A fix being available also does not mean your servers have it, and patching does not remove access an attacker already gained.

Who needs to check

The bug only bites when several conditions line up. That is good news for most estates, but it means you should check your own systems rather than assume. A server is exposed when all of the following are true:

• OpenSSH is older than 10.6p2 (or, on Alpine, the package is older than the fixed version for its branch).
• The system is Linux using musl libc, and sshd was built without PAM. Alpine's default openssh-server package is built this way. Other musl-based systems such as OpenWrt, Buildroot, Yocto builds and some container images may be affected, depending on how they build OpenSSH.
• Password authentication is enabled in sshd. This is the OpenSSH default, so unless someone switched it off it is on.
• An account that can log in over SSH has only an asterisk in its password field in /etc/shadow (the usual marker for 'no password set'), and at least one other local account has a real SHA-256 or SHA-512 password hash.
• The SSH port is reachable by the attacker.

Why a long password gets in

When an account has no usable password hash, sshd borrows a salt from another account so that failed logins take about as long as real ones. On musl, the crypt function refuses SHA-256 and SHA-512 passwords longer than 256 bytes and returns a single asterisk to signal an error. That asterisk is exactly what a password-less account has stored, so the two strings match and the login is treated as correct. The OpenSSH release notes say the root cause lies outside sshd but that sshd can be made to avoid it, which is what 10.6p2 does.

Not affected: systems that use glibc, systems where sshd uses PAM, servers with password authentication turned off, accounts locked with an exclamation mark rather than an asterisk, and Dropbear. Red Hat states its products are not affected because RHEL links OpenSSH against glibc and uses PAM by default.

Alpine deserves a specific mention. Its official cloud images from 3.18.11 to 3.24.3 ship an 'alpine' account with a disabled password and passwordless doas. That is not reachable on first boot, but if someone later gives another account a password hash, the combination can become exploitable and the route leads straight to root.

Check whether a server is exposed

These checks only read information. Run them in a shell on the server itself, as root where noted. They assume Alpine paths and tools. On another musl distribution, use its own package manager and check where sshd is installed. The shadow file checks print account names only, never the hashes themselves.

1. Confirm the C library. On musl, the first line of output names musl libc. The command may print to the error stream and return a non-zero exit code, which is normal on musl.
   shellCopy

   ldd --version

2. Check the installed OpenSSH package. Compare it against the fixed versions for your Alpine branch in the table below this list. A version at or above the fixed one is patched, but only once sshd has been restarted.
   shellCopy

   apk info -v openssh-server

3. Check whether sshd links against PAM. If nothing about PAM appears in the output, the build is almost certainly without PAM, so treat the server as in scope.
   shellCopy

   ldd /usr/sbin/sshd | grep -i pam

4. As root, check the effective sshd settings for password logins. If passwordauthentication shows yes, the condition is met. Remember that Match blocks in the configuration can change the value for particular users or addresses.
   shellCopy

   /usr/sbin/sshd -T | grep -i -E 'passwordauthentication|permitrootlogin'

5. As root, list accounts that have no password. Any SSH-eligible name in this list is a potential target.
   shellCopy

   awk -F: '$2=="*" {print $1}' /etc/shadow

6. As root, check whether any other account has a SHA-256 or SHA-512 hash. If this prints at least one name, and step 5 listed a login-capable account, all the account conditions are met. If it prints nothing, the known exploit route has nothing to borrow, though patching is still the right move.
   shellCopy

   awk -F: '$2 ~ /^\$[56]\$/ {print $1}' /etc/shadow

Fixed Alpine package versions

Alpine backported the fix, so its package numbers look lower than 10.6p2 and are not a sign of an unpatched system. According to Alpine's security tracker, the fixed openssh versions 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

Patch and restart sshd

The restart is the part people forget. The old sshd process keeps running from memory after the package is replaced, so an updated server can stay vulnerable until the service is restarted. Restarting sshd normally leaves existing sessions alone but briefly interrupts new connections. Keep one logged-in session open until you have proved a fresh login works, and have console access available in case something goes wrong.

For containers and virtual machine images, updating a running instance is not enough. Rebuild the image from a patched base, redeploy it and retire the old one. For musl systems other than Alpine, install your distribution's fixed package or OpenSSH 10.6p2 or later.

1. Refresh the package index.
   shellCopy

   apk update

2. Apply the pending updates. This upgrades every package with an available update, not just OpenSSH, so schedule it as you would any routine update.
   shellCopy

   apk upgrade

3. Validate the configuration, then restart sshd. A syntax error would otherwise show up only when the service fails to come back.
   shellCopy

   /usr/sbin/sshd -t
   rc-service sshd restart

4. Confirm the new version, then open a second, separate SSH session and sign in using your normal method. When it works, you can close the original session.
   shellCopy

   apk info -v openssh-server

If you cannot patch today

OpenSSH developer Damien Miller has urged administrators of affected systems to set PasswordAuthentication to no or to disable SSH until they can patch. Switching off password logins closes the route entirely, but it will lock out anyone who relies on a password, including you. Before you change anything, confirm that key-based login works for every account that needs access, and keep a console or existing session open.

Narrowing who can reach port 22 also helps, for example through a VPN, bastion host or management network, but it is a reduction in exposure and not a fix.

1. Open /etc/ssh/sshd_config as root and make sure PasswordAuthentication is set to no. sshd uses the first value it finds for a setting, so look for earlier lines or included files that set it to yes.
   textCopy

   PasswordAuthentication no

2. Test the configuration, then check the effective value. The output should read passwordauthentication no. Also check for any Match blocks that turn it back on.
   shellCopy

   /usr/sbin/sshd -t
   /usr/sbin/sshd -T | grep -i passwordauthentication

3. Restart sshd, then open a new session using your key to confirm you can still get in.
   shellCopy

   rc-service sshd restart

Look for signs it has already been used

Standard SSH logs do not record password length, so you cannot search for 'long passwords' directly. The useful signal is a successful password login for an account that should not have a password, such as root, a key-only administrator or the default alpine user. On Alpine with the default syslog set-up, SSH events normally land in /var/log/messages. Other logging set-ups will differ.

Then look at what happened next: unexpected doas or sudo use, newly created accounts, changes to authorized_keys files, new files in /tmp, and outbound downloads. Reports of attempts include short non-interactive commands such as id, uname and hostname, and, in the SANS honeypot data, download-and-execute commands. If an unexplained password login on a no-password account turns up, or you cannot rule one out on an internet-facing server, treat the system as compromised. Isolate it, preserve its logs and rebuild it from a trusted image instead of cleaning it in place. CISA's KEV entry also flags forensic triage as required for US federal agencies under BOD 26-04, which is a sensible model for anyone else.

grep 'Accepted password' /var/log/messages

What the exploitation evidence does and does not show

CISA's KEV listing is the authoritative statement that exploitation has happened. It does not identify victims, and it lists known ransomware use as unknown. Previdian reported that its sensors saw attempts less than nine hours after the CVE was published, and that an attacker obtained root access on a honeypot running real Alpine Linux and OpenSSH. Help Net Security reported eight attempts from one address in Japan, with the commands id, uname and hostname run afterwards. Separately, SANS Internet Storm Center honeypots recorded a rise in very long SSH passwords from 5 November, peaking on 6 November, though not every long password is a genuine exploit attempt.

That is activity against decoy systems, not evidence about any named organisation. Public proof-of-concept code exists, and Previdian has warned that some of it may itself contain malware, so do not run exploit code from unverified repositories to test your own servers. The EPSS score on the CVE record, around 1% when checked, was calculated before the KEV listing was widely reflected and is probabilistic context, not a measure of confirmed attacks.