A Very Long Password Opens Locked Accounts on Alpine Linux Servers

OpenSSH Patches a Login Bypass Hiding in Alpine’s C Library

A fix went out on Thursday, 5 November, for a flaw that lets anyone who can reach a Linux server’s login port sign in to accounts that never require a password. The trick is a very long password.

Who should care: any team running Alpine Linux, the small Linux behind many cloud servers, containers, and network devices, with password logins switched on.

What could go wrong: an attacker who can reach the login port gets into an account that should refuse every password. On Alpine’s official cloud images, that account can act as administrator.

Do this today: turn off password logins on those machines, or install the fixed package and restart the login service.

Worth remembering: a rule like “this account takes no password” only holds if every program that checks it reads it the same way.

What Happened?

OpenSSH shipped version 10.6p2 on 5 November to stop an OpenSSH password bypass reachable through sshd, and says the root cause sits outside sshd itself. Alpine published its advisory and fixed packages for every release from 3.16 to edge the same day. MITRE assigned CVE-2026-123158 later that day and rates it 8.1 (High).

Here’s the bug. On musl, the C library under Alpine, the password hashing function refuses anything over 256 bytes and returns a single asterisk as its error. Accounts with no password store that same asterisk. Send a password of 257 to 1,024 bytes, and sshd matches it.

Four things must line up: sshd checking passwords without PAM (Alpine’s default build), password logins on (the default), an account with an asterisk for a password, and at least one other account with a real password hash. Debian, Ubuntu, Fedora, and PAM setups are not affected.

What’s the Impact?

Official Alpine cloud images from 3.18.11 through 3.24.3 ship an alpine user with no password and passwordless doas, so it can become root. Once any account on that machine gets a real password, one login attempt can hand over the server. No attacks have been reported.

Where “Just Upgrade” Stops Working

Upgrading fixes machines that have a package manager. Most of this code lives elsewhere.

Container images keep the old package until someone rebuilds them. Cloud images from earlier point releases boot unpatched. Routers and appliances built on OpenWrt, Buildroot or Yocto wait on vendor firmware. Alpine releases older than 3.16 get no fixed package at all. Even patched Alpine hosts can fool a scanner, because the fixed packages keep older version numbers (3.24 ships 10.3_p1-r2).

Cycode tested public Docker Hub images that run an SSH server and found a small number exposed under their documented setup, while Gitea, Gogs, and several other popular images ship with password logins off.

So the fleet-wide question is “is password login off?“ and not “which OpenSSH version is this?”

How to Avoid This

• Find every machine, image and device running OpenSSH on Alpine or another musl system with password logins on.
• Turn password logins off, or update OpenSSH and restart sshd. The upgrade alone leaves the old daemon running.
• Rebuild and redeploy container images, and update instances launched from older cloud images.
• Search /var/log/messages for “Accepted password for” on accounts with no password, such as alpine, root or users meant for key logins only. If you find one, treat the machine as compromised, as Alpine advises.
• On Alpine older than 3.16, turning off password logins is the only fix.