Alpine and OpenSSH fix a password bypass bounded by five conditions

Alpine Linux and the OpenSSH project released fixes on 5 November 2026 for an authentication bypass that can admit an attacker to certain accounts that are not meant to accept passwords. The finding was published the same day by researcher Özgün Kültekin of Wakefield, who named it *sshole. OpenSSH issued portable 10.6p2, and Alpine published patched packages.

Alpine’s advisory says the login requires one connection and no second attempt when the vulnerable configuration is present. The practical reach is narrower than the phrase lightweight Linux suggests: exposure depends on conditions that must all hold. The remediation also has an operational step, because replacing the package does not replace a running sshd daemon.

The configuration comes first

Alpine’s advisory sets out the conditions that must coincide. sshd must run on musl, the C library Alpine uses instead of the more common glibc, without PAM, the authentication framework used by many Linux distributions. Alpine’s standard openssh-server package is built that way; openssh-server-pam with UsePAM yes is not affected, while the same package with UsePAM no is. PasswordAuthentication must be enabled. At least one account must have a single asterisk in its password field, the marker for an account with no password. At least one other local account must have a $5$ or $6$ password hash. The password supplied must be from 257 to 1,024 bytes.

That list excludes many systems that the shorthand lightweight Linux can bring to mind. Containers that do not run sshd are outside the issue. So are systems with PasswordAuthentication set to no, accounts locked with an exclamation mark, systems with no dollar-style password hash, and sshd configurations that actually use PAM. A host is not exposed merely because it runs Alpine, and a container is not exposed merely because it uses an Alpine base image.

Other musl-based systems may meet the same conditions, but the wider claims need care. Kültekin names Buildroot and Yocto, while Ars Technica reported that their exposure was not yet confirmed. OpenWrt uses Dropbear as its default SSH server, so the reported issue would concern an OpenWrt device only where OpenSSH had been installed in place of that default.

How the asterisk matches itself

Alpine’s explanation begins with the way sshd checks a password when PAM is absent. It hashes the supplied password with crypt() and compares the result with the stored password field. An account marked with a single asterisk has no usable salt. sshd therefore borrows a salt from another local account that has a real hash. That borrowing behaviour is tied to a 2016 fix for a username enumeration timing issue, according to core-jmp.

On musl, crypt() returns an asterisk as its error indicator when the supplied password is over 256 bytes. That is the same character held in the passwordless account’s field. The comparison therefore succeeds, and sshd treats the login as authenticated. OpenSSH stops accepting the attempt at 1,024 bytes. This is not a way to crack a real SHA-crypt password. It works only against the stored marker for an account that was not meant to accept a password, and only where the other conditions are present. glibc-based systems are outside this chain.

The cloud image trap

Alpine’s advisory identifies a distinct risk in its official tiny-cloud images. Images from 3.18.11 through 3.24.3 ship an alpine user whose password field is an asterisk and whose doas access, Alpine’s equivalent of sudo, requires no password. A fresh image is described as safe, because a machine with no SHA-crypt hash has no salt for sshd to borrow. It becomes exposed as soon as any $6$ hash exists, for example when an administrator sets a console password or user data adds a user with a hashed password.

An attacker who reached the alpine account could then use doas to become root. The default PermitRootLogin setting protects root from a direct password login, but it does not close that route. Images built from 3.21.10, 3.22.8, 3.23.8, 3.24.4 and later include the fixed package. Running instances created from earlier point releases do not become fixed because a newer image exists; each instance still needs the update or the password-login mitigation, followed by a restart.

Fixes and the restart that often gets missed

Alpine 3.21.10, 3.22.8, 3.23.8 and 3.24.4 contain the fixed package. The advisory also lists branch-specific fixed versions from edge back to 3.16, and Alpine published patched packages for branches that no longer receive regular updates. Version 3.21 had reached end of support on 1 November, four days before the advisory, but still received a fixed package. OpenSSH 10.6p2 avoids the problem in sshd.

Upgrading the package is not the end of the repair. Alpine’s advisory is explicit that the package manager does not restart a running sshd, so an operator can see a successful upgrade while the old process continues to accept logins. The useful inventory check is therefore twofold: the installed version and the state of the running daemon. Where updates cannot be applied at once, setting PasswordAuthentication to no and restarting sshd closes the password path. Administrators should confirm that key-based access works and keep the current session open until a new login has been tested.

What detection can and cannot show

The TinyFish publication CURRENT reported that neither project had reported exploitation in the wild, and the available reporting contained no evidence of it. That is an absence of evidence, not a demonstration that no login has occurred. The signal is also less distinctive than a flood of failed attempts. A successful bypass would appear as an accepted password authentication for an account that should have no password.

Alpine advises looking for accepted-password entries for alpine, root or key-only users, reviewing doas use and checking recent user, file and authorised-key changes. If a login cannot be ruled out, the advisory says the machine should be treated as compromised. A lack of failed-login noise proves little. The check depends on the logs available, so it should sit alongside checks for other signs of alteration rather than replace them.

Two disputes that remain open

The CVE status was unresolved in the available material. iTnews, in a report syndicated through Apple News, gave the identifier CVE-2026-123158 and a CVSS score of 8.1. Alpine’s advisory said no CVE identifier had been assigned at the time of writing, and Ars Technica reported that there was no known CVE designation. The identifier was not confirmed by a primary CVE record in the available material. It should therefore be treated as disputed rather than as an established severity score.

The root cause is also contested. OpenSSH characterises it as outside sshd but exploitable through sshd and avoidable there. Musl developer Rich Felker is reported as describing it as erroneous use by the caller rather than a bug in musl. Matt Johnston argued on the oss-sec list that the asterisk error token is not clearly specified in Debian’s crypt(3) documentation and that changing system APIs is problematic. Those are arguments about where responsibility lies, not a resolution of it. The affected configuration and the fixed releases are documented; the fault line is not.

The practical dividing line

The useful question for an operator is not whether a system belongs to a loose category of lightweight Linux, but whether a reachable sshd combines musl, no PAM, enabled password authentication and a passwordless account alongside a SHA-crypt hash. That list can be checked host by host; a base image name alone cannot answer it.

Fixed packages are available across Alpine branches back to 3.16. What remains is fleet-level proof: that each exposed host has the fixed package and that sshd is running the fixed code. The unresolved CVE record and the argument over root cause do not change those steps. They do change how the flaw should be described: as a configuration-specific authentication bypass with a documented fix, not as a blanket verdict on Alpine or other lightweight distributions.

Two things get described as fixed: a package that has been upgraded and a daemon that has been started again, and only the second stops vulnerable code from answering logins. Spotting that gap on a live host means reading a running process, its configuration and the account entries it consults, which is why familiarity with Linux pays off well beyond any single advisory. Anyone weighing that kind of everyday system evidence can explore The Hack Academy’s online cybersecurity training programme, where Linux is one of the listed subject areas, with self-paced learning and practical exercises alongside the theory. It will not settle the CVE question, but it makes the next host you check far less of a mystery.