OpenSSH Rushes Fix for Flaw Letting Long Passwords Unlock Alpine Servers
OpenSSH 10.6p2 fixes a decade-old flaw that let attackers log in to some Alpine Linux servers by typing an overly long password.
The developers of OpenSSH, the software that millions of servers use to accept secure remote logins, have released an emergency update to close a flaw that let attackers sign in to some Linux machines without knowing any password at all. The bug affects systems built on musl, a lightweight software library at the heart of Alpine Linux, a minimalist Linux distribution widely used in containers, cloud images and embedded devices. On vulnerable machines, a password longer than 256 characters could be enough to log in to accounts that were never meant to accept passwords, including, in some setups, the root account.
What happened
OpenSSH version 10.6p2 was released on November 5, according to the Linux news site LWN.net, which reported that the announcement came from Damien Miller, a longtime OpenSSH developer. Miller’s message urged administrators of affected systems to “set PasswordAuthentication=no or disable SSH for these systems IMMEDIATELY,” a quote also carried by the security news site Privacy Affairs.
Alpine Linux moved quickly. The project said it would backport the fix “all the way back to Alpine 3.16,” a release from May 2022, LWN reported. A comment on LWN from an Alpine maintainer said patched packages had been built and pushed for every supported architecture. Privacy Affairs, which listed the specific fixed package versions, reported that Alpine committed its fixes in the hours around Miller’s announcement on the morning of November 5, coordinated universal time.
The flaw is being tracked as CVE-2026-123158 and carries a severity score of 8.1 out of 10, rated “high,” according to SecurityOnline, a cybersecurity news site. Privacy Affairs and LWN, writing earlier, said no identifier had yet been assigned. OpenSSH itself describes the issue as critical.
How the bug works
The flaw was found by researcher Özgün Kültekin, who published a detailed write-up nicknamed “sshhole,” according to Privacy Affairs and SecurityOnline. The problem arises from an unlucky collision between two pieces of software that each behave reasonably on their own.
When an SSH server checks a password without PAM, a common Linux authentication framework, it scrambles the submitted password with a function called crypt() and compares the result to the value stored for that account. On musl, crypt() returns a single asterisk when it cannot process a password that is too long, which for the common SHA-512 hashing method means more than 256 bytes. Separately, Linux systems store an asterisk in the password field of accounts that are not supposed to accept passwords at all.
The result: an attacker sends an oversized password, musl returns “*” as an error, and the server sees that it matches the stored “*” and lets the attacker in. SecurityOnline reported that Alpine said the attack “takes one connection, works every time, and needs no retries.” The new OpenSSH release works around the problem by refusing a match when the stored value is shorter than four characters, Privacy Affairs reported.
According to the reporting, the musl behavior dates to 2012, and a 2022 change in Alpine 3.16 switched the root account’s placeholder from “!” to “*”, which put root itself in the line of fire. Kültekin reportedly ran about 17,600 test logins across different configurations and found that only musl systems without PAM behaved this way.
Both projects have pushed back on blame. OpenSSH said the root cause lies “outside OpenSSH itself,” while Rich Felker, the lead developer of musl, said “it is not a musl vulnerability,” according to Privacy Affairs.
Who is affected
The flaw’s reach is narrow but significant, given how common Alpine is in cloud and container infrastructure. According to SecurityOnline and Privacy Affairs, a system is exposed only if all of the following are true:
- It runs the OpenSSH server on musl, as Alpine does, without using PAM to check passwords.
- Password logins are enabled, which is OpenSSH’s default.
- It has at least one account marked with “*” alongside at least one account with a real password.
Systems using the more common glibc library, PAM-based setups, non-Linux systems such as OpenBSD, and the alternative SSH server Dropbear are not affected, according to Miller’s announcement as summarized by LWN. SecurityOnline reported that Alpine cloud images, which disable password logins, are also safe, as are containers that do not run an SSH server. Reader comments on LWN flagged the SSH add-on for Home Assistant OS, a smart-home platform built on Alpine, as affected, with an update available; that claim could not be independently confirmed.
Exploitation and what comes next
Reports differ on whether attackers are already using the flaw. Privacy Affairs reported no confirmed exploitation, and SecurityOnline initially said neither Alpine, OpenSSH nor the researcher knew of any attacks or public exploit code. An update to SecurityOnline’s article, however, said the threat intelligence firm watchTowr had detected active exploitation attempts, mostly from automated botnets and cryptocurrency-mining operations rather than targeted attackers.
Miller also warned that bugs are now being rediscovered “sometimes within hours,” a reference to how AI tools are speeding up vulnerability hunting, Privacy Affairs reported. That compresses the window administrators have to act once a flaw becomes public.
SecurityOnline noted that installing the updated package does not replace an SSH server that is already running, so the service must be restarted for the fix to take effect. Security researchers also recommend reviewing login records for successful password logins on accounts that should only accept keys, since such entries could indicate a past break-in.
