Alpine Linux Warns of OpenSSH Login Bypass (CVE-2026-123158): Overlong Passwords Open Key-Only Accounts

Cyber · 2026-11-05 · By H.A

OpenSSH 10.6p2 and new Alpine packages fix a bug that let attackers log in to some Alpine servers over SSH with any very long password.

What Happened

Alpine Linux has published an urgent security advisory for OpenSSH. A password authentication bypass, tracked as CVE-2026-123158, lets an attacker log in to some Alpine servers over SSH without knowing the password. The OpenSSH project shipped a fix the same day, 5 November 2026, in portable OpenSSH 10.6p2. Its developers urged anyone affected to disable password authentication immediately if they cannot update right away.

The attack is simple: on a vulnerable system, an overlong password between 257 and 1,024 bytes is accepted for certain accounts. One attempt is enough. Neither OpenSSH nor Alpine reported attacks in the wild at the time of the advisory.

Technical Details

The flaw affects Linux systems where sshd is built on the musl C library and runs without PAM. Alpine is the best-known platform that works this way. According to the official CVE description, sshd lacked a workaround for a password check that misreads whether a stored value is really a password hash.

The OpenSSH developers say the root cause sits outside sshd. Because it is reachable through sshd, they added a workaround there in 10.6p2.

Alpine says a system is only exposed when all of these are true:

• it runs the default openssh-server package (built without PAM), or openssh-server-pam with UsePAM no
• password authentication is enabled, which is the default
• at least one account has a password field of exactly *, which is typical for key-only users, directory-service users and some cloud image default users
• at least one local account has a modern $5$ or $6$ password hash

Accounts locked with !, systems using PAM, glibc-based distributions and non-Linux systems are not affected.

Who Is Affected

The affected releases are Alpine 3.21 to 3.24 and edge, plus the end-of-life 3.16 to 3.20 releases. Tiny-cloud images from 3.18.11 to 3.24.3 are also included.

Alpine is everywhere in containers and lightweight cloud machines, so the main risk is to:

• virtual machines and cloud instances built on Alpine with SSH open to the internet
• network and storage appliances that use Alpine underneath
• container images that run their own SSH server, often used for remote access, CI runners or legacy tooling

Containers that do not run sshd are not affected.

Patch Status

Fixed packages are available for every branch:

• 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 down to 3.16: backported fixes (9.7_p1-r6, 9.6_p1-r3, 9.3_p2-r4, 9.1_p1-r7, 9.0_p1-r6)

Alpine also released new point versions 3.21.10, 3.22.8, 3.23.8 and 3.24.4 with the fix included.

What To Do Now

1. Update with apk upgrade -U -a, then restart sshd with rc-service sshd restart. The running daemon keeps the old code until it is restarted.
2. If you cannot update straight away, disable password logins. Add PasswordAuthentication no in a file under /etc/ssh/sshd_config.d/, test with sshd -t, and restart sshd. Make sure key login works before closing your session.
3. Rebuild and redeploy any Alpine-based container images that run sshd.
4. Check /var/log/messages for Accepted password for entries on accounts that have no password or only use keys. If you find one you cannot explain, treat the machine as compromised.

Why It Matters

Authentication bypasses in OpenSSH are rare, and this one is unusually easy to use. It also hits the accounts administrators trust most: key-only users marked * are normally considered impossible to log in to with a password.

The bug also shows how a default build choice, musl without PAM, can change the security of a tool everyone assumes is the same everywhere. Turning off password authentication on SSH servers that use keys costs nothing and would have blocked this bug entirely. Now is a good moment to make it the default across your fleet.

Reef Sentinel has published a full Threat Intelligence briefing with detection commands and hunting guidance for this vulnerability.