Every system carries a small hinge where a convenience becomes a door, and here a single asterisk, the mark a careful design uses to say 'no password here,' turned out to answer a stranger's guess as well. In the lightweight Alpine Linux world, where a compact C library reports its errors in a way glibc does not, an oversized password can make the locked and the open look the same to the login routine. The flaw, catalogued as CVE-2026-123158, has been quietly present since 2016, and it reminds those who run servers that the quiet assumptions beneath their tools deserve the same scrutiny as the
Alpine Linux and OpenSSH Flaw Lets Attackers Bypass Login; Patch Now and Restart sshd
A single asterisk is at the center of a serious security flaw
Mark
Why does one asterisk matter so much?
Mimi
Because it means two different things at once. In a password field it marks an account with no password, and musl's crypt() also returns it as an error for inputs over 256 bytes. The comparison sees a match.
Mark
So the attacker never guesses a password.
Mimi
Right. They send one between 257 and 1,024 bytes and need the name of a passwordless account. Alpine says one account with a 5 or 6 hash on the machine is enough.
Luke
Worth being clear about scope, though. This needs specific configuration: no PAM, PasswordAuthentication on, and those account conditions.
Mimi
True, but PasswordAuthentication yes is the OpenSSH default, and the tiny-cloud images become exploitable once any 6 hash exists.
Mark
Is root in danger?
Mimi
Usually not directly, since prohibit-password blocks root:*. But an account that can reach root through doas gives a route.
Luke
The 2016 origin is attributed to *sshole, the discoverers. I wouldn't treat it as independently confirmed. And nothing in the reporting says the flaw has been exploited in the wild.
Mark
What about other distros?
Mimi
Musl-based ones are potentially vulnerable, like Void and OpenWrt. Wind River says it is still assessing.
Luke
Right, so "potentially" is the honest word there. Only Alpine's own exposure is spelled out in detail.
Mark
What should people do first?
Mimi
Upgrade, then restart sshd, because the upgrade doesn't replace the running daemon. Then check logs.
Der Puls
- A single asterisk, meant to mark an account as locked, has become a way in for anyone who sends a password between 257 and 1,024 bytes.
- Any one account with a real password on a machine is enough to expose every passwordless account on it, widening the reach of the flaw.
- Alpine's tiny-cloud images ship safe on first boot but turn vulnerable the moment an administrator sets a console password, catching many unaware.
- Patched releases 3.21.10, 3.22.8, 3.23.8 and 3.24.4 are out, yet the running sshd must be restarted before the fix actually takes hold.
- Administrators are being told to hunt through logs for suspicious 'Accepted password' entries and to treat any unclear case as a compromise.
Every system carries a small hinge where a convenience becomes a door, and here a single asterisk, the mark a careful design uses to say 'no password here,' turned out to answer a stranger's guess as well. In the lightweight Alpine Linux world, where a compact C library reports its errors in a way glibc does not, an oversized password can make the locked and the open look the same to the login routine. The flaw, catalogued as CVE-2026-123158, has been quietly present since 2016, and it reminds those who run servers that the quiet assumptions beneath their tools deserve the same scrutiny as their locks. Patched releases now exist, and the question left for administrators is less about the code than about whether they can confidently say no one has already walked through.
A security flaw in Alpine Linux, the lightweight server distribution, has turned a single asterisk into a possible key. According to ZDNET's reporting, an attacker who can reach a vulnerable machine's Secure Shell port and knows the name of a passwordless account can log in by sending a password between 257 and 1,024 bytes long. The flaw, tracked as CVE-2026-123158, was described by security engineer Gregory Bryant as an authentication bypass that comes down to one character, and the group *sshole, which uncovered it, says the underlying side effect has been hiding since 2016.
The mechanics are simple. Where OpenSSH is built without PAM, it hashes a login attempt with the C library's crypt() function and compares the result to the stored password field. In musl, the library Alpine uses, crypt() returns an asterisk as an error signal when input exceeds 256 bytes, and that same asterisk is what a passwordless account holds. The two match, and the door opens. Glibc systems such as Debian, Ubuntu and Fedora return NULL on error and are not affected.
Alpine says every release it checked is vulnerable, and the danger is quiet in the most common setups. Its tiny-cloud images are safe on first boot but become exploitable once any real password hash exists on the machine, which happens easily. Other musl-based systems, including Void Linux, OpenWrt and the Yocto Project, may also be exposed, and Wind River says it is reviewing its own exposure.
Fixed packages arrived on Thursday for every supported branch back to 3.16. Administrators should run apk upgrade and restart sshd, since upgrading alone does not replace the running daemon. Those who cannot update should disable password authentication after confirming key login works, and search their logs for suspicious password logins. Alpine's guidance is blunt: if a login cannot be ruled out, treat the machine as compromised.
A single asterisk is at the center of a serious security flaw in Alpine Linux, the lightweight server distribution. According to ZDNET's reporting, an attacker who can reach a vulnerable machine's Secure Shell port, and who knows the name of a passwordless account, can log in by sending a password between 257 and 1,024 bytes long. The flaw is tracked as CVE-2026-123158. Security engineer Gregory Bryant described it on LinkedIn as an authentication bypass that comes down to one character, in contrast to the complex logic chains behind most such bypasses.
The mechanics are simple. When OpenSSH is built without Pluggable Authentication Modules (PAM), it checks a password by hashing the attempt with the C library's crypt() function and comparing the result to the account's stored password field. In musl, the lightweight C library Alpine uses, crypt() returns the string * as an error indicator when the input runs past 256 bytes. That is also exactly what the password field holds for an account with no password, such as a key-only account. The two strings match and the login succeeds.
Two conditions apply. The attacker needs the name of a passwordless account, and the machine needs at least one other account with a 5 or 6 password hash. Per Alpine, a single user with a password is enough to make every passwordless account reachable. The group *sshole, which uncovered the problem, says the underlying side effect has been hiding since 2016.
Alpine says every release it checked is affected: 3.21 through 3.24, edge, and the older 3.16 to 3.20 branches. Exposure requires the openssh-server package built without PAM, or openssh-server-pam with UsePAM set to no, along with PasswordAuthentication set to yes, which is the OpenSSH default. Root is not directly exposed in most cases. It has shipped as root:* in the base image since about Alpine 3.16, but the default PermitRootLogin prohibit-password setting blocks it. Even so, any other account that can become root, through doas for example, still gives an attacker a path there.
Alpine singled out its official tiny-cloud images, versions 3.18.11 through 3.24.3. These ship with an alpine user that has a * password field and passwordless doas. They are safe on first boot but become exploitable once any 6 hash exists on the machine, which happens when an administrator sets a console password or when user data adds a user with a hashed password. ZDNET notes that this means, essentially, all of them.
Other musl-based systems are potentially vulnerable too: Adélie Linux, Void Linux, Sabotage Linux, OpenWrt, an Android variant, and the Yocto Project, which is used to build embedded Linux distributions. Wind River, maker of the commercial Wind River Linux, told ZDNET it is actively reviewing the reported vulnerability and assessing its potential impact. Systems using glibc, which is almost all of the rest, return NULL on error, and sshd already rejects that. Debian, Ubuntu and Fedora are not affected. Also unaffected, per Alpine: containers that do not run sshd, systems with password authentication disabled, systems using openssh-server-pam with UsePAM yes, locked accounts marked with !, and cloud images configured through cloud-init, which writes PasswordAuthentication no.
Alpine released 3.21.10, 3.22.8, 3.23.8 and 3.24.4 on Thursday, with the OpenSSH fix among the security changes, and published fixed packages for each release back to 3.16. Alpine 3.21 reached end of support on Nov. 1. OpenSSH 10.6p2 avoids the problem in sshd, and Alpine's stable branches carry a patch for the same issue. The flaw arrived only days after Alpine avoided a serious problem in its GitLab implementation.
Administrators should run apk upgrade -U -a and then restart the daemon with rc-service sshd restart. Alpine stressed that upgrading the package does not replace the running daemon. Anyone unable to update should set PasswordAuthentication no and restart sshd, after confirming key login works. To check for abuse, search /var/log/messages for "Accepted password for" lines naming an account with no password, and review doas use, recently created users, files and authorized keys. Alpine's guidance is blunt: if a login cannot be ruled out, treat the machine as compromised.
Bemerkenswerte Zitate
If you cannot rule out a login, treat the machine as compromised.— Alpine Linux guidance to administrators
Wind River is actively reviewing the reported vulnerability and assessing its potential impact.— Wind River representative, paraphrased
Möchten Sie die ganze Geschichte?
Das Original lesen bei ZDNET ↗
Technology