A Password Longer Than 256 Characters Can Unlock Accounts That Should Have No Password: Patch Alpine and Other musl SSH Servers Now
OpenSSH shipped an emergency fix for a flaw nicknamed sshole that lets an attacker log into certain Alpine Linux and other musl-based accounts that were meant to reject passwords. Here is who is exposed, why a long password works, and what to do today.
If you run OpenSSH on Alpine Linux—or another musl-based system—with password logins still on, stop and check today. A newly disclosed flaw lets an attacker who can reach your SSH port log into accounts that were supposed to have no password at all, simply by submitting an oversized password.
The picture below draws on The Hacker News, SecurityWeek, and BleepingComputer, which cover Alpine’s advisory, OpenSSH 10.6p2, and the researcher’s write-up.
Who is actually exposed
You are in the danger zone only when all of these are true at once:
- The machine uses musl (Alpine, and in some setups OpenWrt, Buildroot or Yocto), not glibc distributions such as Debian, Ubuntu or Fedora.
- sshd is built without PAM—Alpine’s standard
openssh-serverpackage is—or PAM is turned off. - PasswordAuthentication is still yes (OpenSSH’s default).
- At least one account has exactly
*in its shadow password field (key-only users, Alpine’srootsince about 3.16, thealpinecloud-image user, and some directory users). - At least one other local account already has a real
$5$or$6$password hash.
Debian, Ubuntu, Fedora and other glibc systems, and machines that check passwords through PAM, are not affected. Containers that do not run sshd are not affected. Accounts locked with ! are not affected. OpenWrt’s default Dropbear SSH is not affected; the risk there appears only if someone installed OpenSSH.
Why a long password works
Without PAM, sshd hashes the attempted password with the C library’s crypt() and compares the result to the stored field. An account with no password stores only *. Musl’s crypt() also returns * when the submitted password is longer than 256 bytes. OpenSSH then sees a match. The usable range is roughly 257 to 1,024 characters—sshd’s own password length cap. SecurityWeek tracks the issue as CVE-2026-123158 and rates it 8.1; OpenSSH calls the fix critical. Researcher Özgün Kültekin of Wakefield reported it. OpenSSH developer Damien Miller says the root cause sits outside sshd, but sshd can be used to exploit it, and the team shipped 10.6p2 quickly after seeing AI agents rediscover similar bugs within hours.
Alpine notes that an attacker who can reach the SSH port can log in without knowing any password, in one connection, every time. Official Alpine tiny-cloud images from 3.18.11 through 3.24.3 give the alpine user passwordless doas; once any $6$ hash exists on the box, that path can become root. Default PermitRootLogin prohibit-password still blocks a direct root password login unless that setting was changed.
What to do today
- On Alpine, update packages (
apk upgrade -U -aor at least upgrade openssh) and restart sshd—the package update does not restart the running daemon by itself. Point releases such as 3.21.10, 3.22.8, 3.23.8 and 3.24.4 already include the fixed package; older tiny-cloud instances still need the update. - If you build OpenSSH yourself, move to 10.6p2.
- If you cannot update yet: confirm key-based login works, keep your current session open, set
PasswordAuthentication no, test withsshd -t, restart sshd, and confirm withsshd -T. - Search logs for
Accepted passwordlines for accounts that should never accept a password (alpine,root, key-only users). Alpine’s advisory says that if you cannot rule out a login, treat the machine as compromised and reviewdoasuse, new users, files and authorized keys.
As of the reports we used, no attacks using the flaw had been reported in the wild, but public proof-of-concept material exists.
What this means for your company
Many small businesses never think of Alpine until a container host, appliance image or cloud template shows up in the inventory. This is a reminder that “password disabled” on a musl box is not the same as “password logins off,” and that a package update without a service restart leaves the old daemon running. Inventory every host that listens on port 22, know which ones use Alpine or other musl builds, turn off password authentication wherever keys are enough, and make restarting sshd part of the patch checklist.
Not sure which of your servers, appliances or cloud images still accept SSH passwords, or which ones run Alpine under the hood? Reach out to Layer 7 Data Solutions to discuss how we’ve helped companies similar to yours.
About The Author
