Asterisk bypass in musl OpenSSH

An account locked down by replacing its password hash with an asterisk is supposed to be unloggable by password. On some musl-based Linux systems, a researcher says, that asterisk can be matched by an attacker's oversized password input, opening a session as an account that was meant to be closed to password authentication entirely.

The vulnerability, which researcher Ozgun Kultekin calls "*sshole," was released with full details today. It affects OpenSSH servers on distributions built on the musl C library, including Alpine Linux, OpenWrt, Buildroot, and Yocto, under a specific set of authentication conditions.

How the asterisk trick works

On Linux, an account can be prevented from logging in with a password by placing an asterisk (*) in the password field of /etc/shadow. Because the asterisk is not a valid password hash, no password should ever hash to a value that matches it, so the account stays closed to password logins even though it still exists on the system.

OpenSSH's behavior around accounts without usable password hashes changed in 2016. A patch addressing a username enumeration flaw tracked as CVE-2016-6210 made the daemon perform password hashing even when an account had no usable hash, so that response timing would not reveal which usernames were valid. That included accounts configured with the asterisk to block password logins.

The problem sits in how musl's crypt() function behaves. According to Kultekin's writeup, musl returns an asterisk when password hashing fails, including when a submitted password exceeds its 256-byte limit. An attacker who submits an oversized password can therefore cause OpenSSH to compare the returned asterisk against the account's stored asterisk, and the comparison succeeds, resulting in a successful login.

Kultekin is explicit that the flaw does not allow attackers to bypass passwords on accounts that have valid password hashes. The failure mode is specific to accounts whose password field holds an asterisk.

The conditions an attacker needs

Exploitation is not universal. Kultekin lists five requirements that must all be in place for the attack to work:

• OpenSSH must be running on a musl-based Linux system, such as Alpine Linux, OpenWrt, Buildroot, or Yocto.
• PAM authentication must be disabled, as it is by default in Alpine Linux's openssh-server package.
• SSH password authentication must be enabled.
• At least one account must have an asterisk as its password hash.
• Another account must have a valid password hash.

Systems that use glibc, including Debian, Ubuntu, and Fedora, are not vulnerable. Nor are systems where PAM authentication is in use.

The condition requiring a second account with a valid password hash matters for how the daemon is configured to respond, and Kultekin's listed requirements frame the flaw as one that appears in a particular combination of defaults and deliberate lockouts rather than in every musl deployment.

Cloud images with a passwordless path to root

The most consequential exposure Kultekin describes involves Alpine Linux's official cloud images for AWS and Azure. Those images ship with a default alpine account that has passwordless doas privileges. Because that account's password authentication is disabled, it fits the pattern of a locked-out account, and an attacker who can make the asterisk comparison succeed against it could then use its doas rights to gain root access.

That pairing — a widely deployed base image, a default account, and an escalation path that requires no further credentials — is the scenario where the flaw carries the most weight. Kultekin's disclosure does not describe attacks observed in the wild, and the details released today center on the mechanics and the conditions rather than on reports of exploitation.

Found by automated authentication probing

Kultekin says he found the vulnerability using AI agents, which ran about 17,600 authentication tests across different OpenSSH configurations, malformed password hashes, and oversized passwords. The scale of that test matrix is how a flaw tied to a library's error return value and a byte-length limit surfaced: it requires both a particular hash state and an input that trips musl's hashing failure path.

The flaw itself is not new. Kultekin says it has existed since 2016, meaning the behavior has been present in affected configurations for years before this week's disclosure.

The fix and the workaround

The vulnerability has been fixed in OpenSSH 10.6p2. Alpine Linux administrators are advised to update their OpenSSH packages with the command apk upgrade openssh.

For admins who cannot install the update immediately, Kultekin points to a configuration-level mitigation: turn off SSH password authentication by setting PasswordAuthentication no in the SSH server configuration, then restart SSH. That removes the password authentication path the flaw depends on.

The vulnerable combinations are concentrated in environments where password authentication is deliberately enabled and PAM is not in use, which is the default posture for Alpine's openssh-server package. Admins who have already moved to key-based authentication and disabled passwords are not exposed through this route in the first place.

Checking logs for signs of use

Kultekin also describes how administrators can look for signs of exploitation in SSH authentication logs, specifically password-based logins recorded for accounts that should not permit them.

On Alpine Linux, he says the following command can reveal successful SSH password logins:

grep "Accepted password" /var/log/messages

If those logs show a successful password login for the alpine account, administrators can then check whether that account has password authentication disabled with this command:

grep '^alpine:' /etc/shadow

If the account's password field contains an asterisk but the SSH logs show a successful password login, that combination could indicate the vulnerability was exploited.

Kultekin's disclosure is the primary account of the flaw and its conditions; no independent corroboration of the technical details or of any exploitation has been published alongside it.

Why this matters for musl deployments

The affected set is narrower than it first sounds — glibc-based distributions such as Debian, Ubuntu, and Fedora sit outside it — but the systems inside that set are often the small, containerized, and cloud-native ones where Alpine is a default base image. A flaw that turns a deliberately locked-down account into a password-accessible one undercuts a control admins rely on to retire access without deleting an account.

The path to root on Alpine's official AWS and Azure images is the part worth weighing most for anyone running those defaults. This suggests that teams building on those images should treat the OpenSSH package version as something to verify rather than assume, and should check whether the default alpine account is still present and still carrying passwordless doas rights in their own deployments.

For the broader group of musl users, the practical question is whether password authentication is enabled at all. The mitigation Kultekin recommends — turning it off — is also a posture many security teams already prefer, which means the fix and the hardening step point in the same direction. Admins who update to OpenSSH 10.6p2 close the flaw directly; those who cannot should weigh whether the password path needs to stay open in the meantime.