AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
"OpenSSH on musl linux (alpine, openwrt, buildroot, yocto, and a lot of the docker images you've pulled) has had a little problem since 2016. Accounts that should never take a password at all take any password longer than 256 characters. Yes any." (sshhole.com)
On November 5, 2026 OpenSSH released 10.6p2 and Alpine Linux published security advisories and openssh packages for a password authentication bypass fix in sshd, CVE-2026-123158 nicknamed sshhole. On an affected system, an attacker who can reach the SSH port can log in to an account that has no password by sending a very long password.
The issue is quite simple to understand. OpenSSH checks passwords by hashing them and comparing the result to the stored value. Accounts with no password store an asterisk symbol. When a user provides a password longer than 256 characters, the musl C library fails to hash it and returns that same asterisk symbol. So OpenSSH sees a match and grants us access to the shell.
The bug affects OpenSSH built against the musl C library without PAM, which is the default openssh-server package on Alpine.
Mitigation
Alpine Linux has backported the fix to all supported branches so I strongly encourage you to update the OpenSSH package to the fixed version. If you somehow cannot update immediately, disabling password authentication should be enough.
A simple PoC to check wether you are exposed has been published on github
References