CVE-2026-123158 (SSHole): a long password logs in to some Alpine Linux servers over SSH

What the flaw does

Alpine and a few other small Linux distributions use musla compact C library that supplies the basic functions programs rely on; most large distributions use glibc instead and build OpenSSH without PAMa Linux framework that handles logins; with it, sshd hands password checks to a separate module. In that setup, sshd checks a password itself: it hashes what the user typed and compares the result with the hash stored for the account.

Accounts that have no password, such as root on recent Alpine images or users meant to log in only with SSH keys, store a single * in that field. According to a technical analysis by the security firm Ostorlab, musl gives up on passwords longer than 256 bytes and returns the text * as its error signal. sshd then compares that * with the stored *, finds a match and lets the user in. The CVE record describes the same problem more briefly, as a misreading of "whether a string is intended to be a password hash".

OpenSSH says it considers the root cause to be "outside OpenSSH itself" but that it can block the bypass in sshd. The fix makes sshd reject stored hashes shorter than four characters, so a lone * can never match.

Who is affected

Alpine's advisory lists four conditions that must all be true:

1. sshd runs without PAM: the openssh-server package, or openssh-server-pam with UsePAM no.
2. PasswordAuthentication is yes, which is the OpenSSH default.
3. The machine has an account whose password field is *. On Alpine this includes root (in the base image since about version 3.16), key-only users, users from directory services such as sssd or winbind, and the alpine user in the tiny-cloud images.
4. At least one local account has a real password hash of the $5$ or $6$ type.

Logging in directly as root also needs PermitRootLogin yes, but Alpine warns that doas can give another path to root. Locked accounts (! in the password field) are not affected, and neither are Docker containers that do not run sshd.

How serious it is

The CVE record, written by MITRE as the CNACVE Numbering Authority, an organization allowed to assign CVE IDs and write the official description, gives a CVSS 3.1 score of 8.1 (High) with the vector AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H. OpenSSH calls the issue critical. Alpine is blunter: an attacker who can reach the SSH port needs one connection and a long password, and it "works every time" when the conditions are met.

Attacks so far

Demonstration code appeared on GitHub soon after the release, and CISA's assessment in the CVE record lists public proof of concept. As of November 8, the flaw is not in CISA's catalog of exploited vulnerabilities.

Two companies that run sensors on the internet have published what they see. GreyNoise tagged the first attempt on November 5 at 18:34 UTC and says it confirmed successful exploitation of its own deliberately vulnerable decoys from November 7, with 14 events after login from four attacker addresses. Previdian counted 19 attempts from 12 addresses in 8 countries by November 8, but notes that its data does not show whether any attempt succeeded. Neither company has reported a real organization being hit.

OpenSSH developer Damien Miller wrote that the team learned of the problem only the day before the release and moved fast because AI agents now rediscover published bugs "within hours".

What to do now

1. On Alpine, run apk upgrade -U -a and then rc-service sshd restart. Alpine stresses that the upgrade alone does not replace the sshd that is already running. The point releases 3.21.10, 3.22.8, 3.23.8 and 3.24.4 already include the fix.
2. On other Linux systems built with musl and without PAM, move to OpenSSH 10.6p2 or your distribution's patched package.
3. If you cannot update yet, set PasswordAuthentication no. Check first that your SSH key login works, keep a session open while you change it, and confirm with sshd -T | grep -i passwordauthentication. Our step-by-step guide to switching SSH to key logins shows how to do it without locking yourself out.
4. Look for signs of a break-in. Alpine suggests searching /var/log/messages for "Accepted password for" on accounts that have no password, such as root, alpine or key-only users, and reviewing doas use, new users and authorized_keys files. If you cannot rule out a login, treat the machine as compromised.
5. If you build container images that run sshd, rebuild them from an updated Alpine base and recreate the containers.

This is the second login bypass of the week: on SonicWall firewalls, a VPN flaw lets attackers skip SAML and multi-factor authentication.