A newly disclosed OpenSSH flaw could let a remote attacker log in without a valid password on certain Alpine Linux systems — including accounts that were deliberately configured for key-only authentication and were never meant to accept a password at all.

OpenSSH shipped Portable release 10.6p2 on November 5, 2026 to close the hole, which affects Linux systems that use the musl C library instead of glibc and that run OpenSSH without PAM authentication — a configuration that happens to be Alpine Linux’s default. Alpine has published its own advisory confirming the issue and has not yet been assigned a CVE identifier at the time of writing. The research behind the discovery, published by Özgün Kültekin of Wakefield on sshhole.com, traces the bug to a subtle interaction between how OpenSSH checks passwords and how musl’s cryptographic hashing function handles unusually long input.

How an Overly Long Password Becomes a Skeleton Key

The mechanics are almost absurdly simple once explained. Without PAM in the picture, OpenSSH’s own sshd process hashes a submitted password and compares the result against the value stored in the system’s password database. For an account that was set up without a usable password — marked in the system with a bare asterisk rather than a hash — sshd normally borrows the salt from a different account to perform that comparison.

The problem appears when an attacker submits a password between 257 and 1,024 bytes long. Alpine’s musl library rejects passwords that long during hashing and, instead of simply failing, returns an asterisk as a generic error marker. That asterisk happens to be exactly what’s stored in the field for an account with no real password set — so the comparison that was supposed to fail instead reads as a match, and the login succeeds. A password of three hundred repeated “A” characters is enough to trigger it; the content of the password is irrelevant, only its length matters.

For the attack to work, several specific conditions need to line up: the targeted account’s password field must contain only an asterisk, a separate local account on the same system must have a real password hash using the $5$ or $6$ format, and password authentication must be enabled on the server at all. That last detail matters because it means simply adding a password to one account on a server can inadvertently expose a completely different, previously passwordless account to remote compromise.

Who’s Actually at Risk

Systems running Alpine’s standard openssh-server package without PAM are the ones exposed; servers configured with openssh-server-pam and UsePAM yes are not affected by this particular bug. Alpine container images with no SSH server actually running are also not exposed on their own — simply using an Alpine-based container doesn’t create the vulnerability by itself.

One specific scenario Alpine calls out: its official tiny-cloud cloud images, spanning versions 3.18.11 through 3.24.3, ship with a built-in “alpine” account that has passwordless administrative access via doas. On systems where a qualifying password hash gets added elsewhere, that account becomes remotely exploitable, potentially giving an attacker a path to root — though default configurations still block direct root password logins unless an administrator has changed that setting.

What Administrators Should Do Now

Alpine’s guidance is straightforward: run apk upgrade -U -a and then restart the SSH daemon with rc-service sshd restart, since updating the package alone leaves the old, vulnerable daemon running in memory. Fixed releases are available at 3.21.10, 3.22.8, 3.23.8 and 3.24.4, along with patched packages for several older branches — administrators should note that a lower-looking version number doesn’t necessarily mean a system is still vulnerable, since patches have been backported.

Where immediate patching isn’t possible, Alpine recommends disabling password authentication entirely (PasswordAuthentication no) after first confirming key-based access works, and restarting sshd while keeping an existing session open as a safety net. Security teams should also review authentication logs for “Accepted password” entries tied to accounts that were never supposed to have a password, along with any unexpected privilege-escalation activity or newly added SSH keys. Alpine’s advisory is blunt on this point: where unauthorized access can’t be ruled out, treat the machine as compromised rather than assuming the patch alone resolves the incident.