OpenSSH Password Bypass on Alpine Needs Three Conditions, Not One

An attacker who can reach port 22 on an Alpine Linux server can log in without a password, in one connection, if three conditions hold: sshd runs without PAM, one account has * as its password field, and another account has a $5$ or $6$ hash. CISA added the flaw, CVE-2026-123158, to its Known Exploited Vulnerabilities catalog on November 9 and set a federal due date of November 12.

The trigger is a password between 257 and 1024 bytes long. Alpine published its advisory and fixed packages on November 5, and OpenSSH shipped Portable OpenSSH 10.6p2 the same day.

The mechanism in Alpine's advisory

Alpine's advisory explains the cause in three sentences. Without PAM, sshd hashes the submitted password with crypt() and compares the result to the stored field. musl's crypt() returns * as an error value for keys over 256 bytes. An account with no password stores *, so the comparison matches and the login succeeds.

That makes the bug a musl behaviour that OpenSSH can avoid, not an OpenSSH logic error. The OpenSSH release notes call the 10.6p2 change a "critical security workaround" for Linux systems using musl libc with PAM disabled, and say the project considers the root cause to be outside sshd. The Alpine advisory credits Özgün Kültekin of Wakefield with the report, and Damien Miller and Darren Tucker of the OpenSSH project with the fix.

Who is and is not affected

The headline "OpenSSH authentication bypass" is wider than the real exposure. CISA's catalog entry says only "OpenSSH on Linux," while Alpine's list is narrower.

Configuration	Affected
openssh-server built without PAM, PasswordAuthentication yes	Yes
openssh-server-pam with UsePAM no	Yes
openssh-server-pam with UsePAM yes	No
PasswordAuthentication no	No
Locked accounts (! in the password field)	No
Alpine cloud-init images	No, they set PasswordAuthentication no

PasswordAuthentication is on by default in OpenSSH. Alpine checked releases 3.21 through 3.24 and edge, plus the unsupported 3.16 to 3.20.

The cloud-image twist

The official qcow2, VHD and AMI images from 3.18.11 through 3.24.3 ship an alpine user with a * password and passwordless doas, per the advisory. They are safe on first boot. They become exploitable once any $6$ hash exists on the machine, and the attacker then gets a shell as alpine and uses doas to reach root.

Fixed versions

Alpine published fixed openssh packages back to 3.16, even though 3.21 reached end of support on November 1.

Branch	Fixed package
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

Run apk upgrade -U -a and then restart sshd. The advisory warns that "upgrading the package alone does not replace the running daemon," so a patched package on disk can sit beside a vulnerable process in memory.

What is not known

At the time of Alpine's writing no CVE had been assigned, so the identifier arrived after the advisory. eSecurityPlanet says CISA's listing confirms active exploitation. Neither CISA nor Alpine publishes who is exploiting it, against which systems, or since when.

If patching must wait, set PasswordAuthentication no in a drop-in file under /etc/ssh/sshd_config.d/, restart sshd, keep the current session open while testing, and confirm with sshd -T | grep -i passwordauthentication. To look for past abuse, search /var/log/messages for Accepted password for on accounts that have no password, such as alpine or root. Alpine's advice is to treat any machine where a login cannot be ruled out as compromised.

The Terminal has covered a plaintext admin token with no expiry at Zeabur and Apache httpd 2.4.71 as well. The federal deadline for this one is November 12.