Operators running Alpine containers should treat every exposed SSH port as open until they move to OpenSSH 10.6p2.
A flaw tracked as CVE-2026-123158 lets a remote party log into accounts that were never supposed to accept a password. The Alpine team put it plainly in its advisory: one connection is enough, it works every time, and no retries are needed.
Previdian, the threat intelligence firm founded by Ryan Dewhurst, watched it happen. The first probe landed under nine hours after CVE publication. Attackers tore through a honeypot running genuine Alpine Linux and reached root, then ran id, uname and hostname over non-interactive sessions. Eight attempts have been counted, all from one Japan-based address, 89.116.89[.]18.
The asterisk that was never a hash
Wakefield researcher Ozgun Kultekin traced the behaviour to a 2016 change meant to stop username enumeration. Musl, the C library Alpine ships, returns a single asterisk when it refuses a SHA-512 password past 256 bytes. That asterisk is exactly what sits in the shadow entry for passwordless accounts, so sshd compares a match and lets the caller in.
Where the exposure actually sits
Servers built on glibc are safe, as is anything authenticating through PAM. Alpine’s default openssh-server package is not, and neither are OpenWrt, Buildroot, Yocto or many published container images. Alpine’s AWS and Azure tiny-cloud images run a passwordless default user with doas, which amounts to root. SOCRadar flags tiny-cloud 3.18.11 through 3.24.3.
What to do
Upgrade to 10.6p2 or later, or turn password authentication off and restart the daemon. CISA has not added the flaw to its catalog, so no federal deadline is driving remediation.
