OpenSSH '*sshole': locked accounts still log in
Unpatched OpenSSH on musl Linux, including Alpine, OpenWrt, and Alpine's images on AWS and Azure, can accept a password on accounts configured to refuse one. Install OpenSSH 10.6p2, or turn password logins off until that package is on the host.
By ZeroDay Times Desk2 min read
![Editorial thumbnail for “OpenSSH '*sshole': locked accounts still log in”, key graphic on a teal and coral columns card, [ ZERO-DAY ] badge, and the ZeroDay Times mark.](/images/articles/openssh-sshole-locked-accounts-still-log-in.svg)
OpenSSH on Linux distributions that use the musl C library can accept a password login for an account that was set so no password should work. Researcher Ozgun Kultekin published the bug on November 5, 2026, under the nickname *sshole. The behavior dates to 2016. The release that closes it is OpenSSH 10.6p2.
The exposed set is specific. It is OpenSSH on musl, which means Alpine Linux, OpenWrt, Buildroot, and Yocto, when password authentication is on and the login path is not going through PAM. Alpine’s openssh-server package leaves PAM off. Debian, Ubuntu, Fedora, and other glibc systems sit outside this bug. A host that authenticates through PAM sits outside it as well.
Alpine’s official images on Amazon Web Services and Azure ship a default account named alpine. Once a session exists, that account can raise itself to root without a separate password, through passwordless doas. A login that should have been impossible on that account is a root path on those images.
The flaw applies to accounts configured so password login is refused. Accounts that hold a real password hash still depend on that password. On an unpatched musl host, the lock on the first kind of account does not hold.
What to install, and what to turn off
Move OpenSSH to 10.6p2 or any later build your distribution ships for this bug. On Alpine, upgrade the openssh package from the distro channel and read back the version the host reports. A banner that still shows an older build is still in the bug.
If the package cannot land today, turn SSH password authentication off and restart the service. Key-based login is the path that remains. Cover appliances built with OpenWrt, Buildroot, or Yocto in the same pass as the Alpine servers. A router image nobody has signed into since the last site visit is still an SSH server.
Then read the authentication log for successful password logins on accounts that are supposed to refuse them. On the Alpine cloud images, a password acceptance for the alpine account is the line that matters. If that account is configured to refuse passwords and the log shows that it accepted one, treat the host as compromised. Rotate the credentials it could reach, replace any trust that account held, and rebuild the image if you cannot account for the session.
Where the update belongs
Put 10.6p2 on the musl fleet first. glibc distributions use a different library, and this bug does not land there. A musl server that already requires keys, with password authentication off, is already on the mitigation. The remaining work is the version string on every musl SSH daemon that still accepts passwords.
The disclosure is public as of today. A lock that has been wrong since 2016 is now a documented login.
This briefing relies on public reporting by BleepingComputer and on Ozgun Kultekin’s disclosure. It does not include exploit procedures.
Corrections and tips:[email protected]