OpenSSH and musl libc vulnerability on Alpine Linux lets you log in without a password via an overlong string

A vulnerability in the interaction between OpenSSH and the musl libc library allows an attacker to log in to an account with the password disabled by sending an SSH string between 257 and 1024 bytes long. The primary systems affected are Alpine Linux servers where the openssh-server package is built without PAM support. Exploitation requires only a single connection — the attack works on the first attempt. A fix is available in OpenSSH 10.6p2 and in updated Alpine packages for the 3.16 through 3.24 branches. Administrators of affected systems must immediately update the packages and restart sshd or disable password authentication.

Technical details of the vulnerability

The vulnerability has been assigned the identifier CVE-2026-123158 — according to the entry in the GitHub Advisory Database, it is rated as high severity with a provisional CVSS score of 8.1. It should be noted that this entry is marked as “unreviewed”, and neither OpenSSH nor Alpine has published its own CVSS assessment.

According to the Alpine Linux security advisory, successful exploitation requires four conditions to be met simultaneously:

• The server uses the openssh-server package without PAM (or openssh-server-pam with UsePAM no);
• The PasswordAuthentication parameter is set to yes (the default value in OpenSSH);
• The target account’s password field in /etc/shadow contains * — that is, no password is set (typically for accounts that use only SSH keys);
• The system has at least one other account with a password hash in $5$ (SHA-256 crypt) or $6$ (SHA-512 crypt) format.

There is a discrepancy between sources regarding the minimum password length that triggers the vulnerability: the Alpine advisory specifies 257 bytes, whereas the GitHub Advisory Database entry lists 256 bytes. In both cases, the upper bound is 1024 bytes — this is a limitation of sshd itself.

Vulnerability mechanism

The problem arises at the intersection of three components: error handling in musl’s crypt() function, sshd’s password verification mechanism when PAM is disabled, and the format in which account data is stored.

When sshd runs without PAM, it hashes the supplied password itself using crypt() and compares the result with the stored value. For accounts without a password, the hash field contains the character *. Because this string is too short to extract a salt, sshd borrows a salt from another account that has a real hash. This salt-borrowing mechanism was introduced in 2016 to fix CVE-2016-6210, which allowed attackers to determine existing user names based on the server’s response time.

The key element is musl’s behavior: when processing $5$ and $6$ hashes, the crypt() function refuses to work with passwords longer than 256 bytes and returns * as an error indicator. This design decision was made in 2012 — instead of returning NULL on error, musl began returning a “non-matching hash” because many programs were not checking for NULL. However, the return value * matches what is stored in /etc/shadow for accounts without a password, so sshd treats the check as successful.

Notably, the OpenSSH and musl developers differ in their assessment of the root cause. According to the OpenSSH 10.6p2 release notes, the OpenSSH team considers the core issue to be external to sshd, even though it can be mitigated on sshd’s side. musl developer Rich Felker, in turn, argues that the problem lies in how the calling program handles the return value of crypt().

Impact

All Alpine Linux versions from 3.16 through 3.24 and the edge branch are affected if configured as described. Systems based on glibc, as well as any configurations with PAM enabled, are not vulnerable.

Cloud Alpine images based on tiny-cloud from versions 3.18.11 through 3.24.3 deserve particular attention. They contain an alpine account with a password field set to * and the right to run commands via doas without a password. These images are safe on first boot, but become vulnerable as soon as the system has at least one $6$-format hash — for example, after an administrator sets a password for console access. In that case, an attacker can log in as alpine and obtain root privileges via doas.

By default, the root account is protected by the PermitRootLogin prohibit-password setting, but this does not help if a compromised account has the ability to perform privilege escalation.

As for other musl-based systems, researcher Özgün Kültekin of Wakefield, who discovered the vulnerability, mentions OpenWrt, Buildroot and Yocto as platforms that require review. However, the practical blast radius is narrower than it might appear: stock OpenWrt uses Dropbear as its SSH server, as stated in the OpenWrt documentation, and Dropbear is not affected. The issue is relevant to OpenWrt only if OpenSSH is manually installed by the administrator.

A public PoC for reproducing the vulnerability is already available, but as of the time of writing there have been no reports of exploitation in real-world attacks.

Remediation recommendations

According to the Alpine advisory, remediation requires the following steps:

1. Update packages: apk upgrade -U -a
2. Restart sshd: rc-service sshd restart — updating the package does not restart the running sshd process automatically.

Fixed packages are included in the point releases Alpine 3.21.10, 3.22.8, 3.23.8 and 3.24.4. The 3.16–3.20 branches, which are already out of regular support, have also received patches.

For self-built OpenSSH installations, you should update to version 10.6p2, which contains a workaround — sshd now rejects a match if the stored password field is shorter than four characters.

If immediate updating is not possible, password authentication must be disabled:

• Make sure SSH key-based login works, and do not close the current session until you have verified the new connection;
• Set PasswordAuthentication no in the sshd configuration;
• Check the configuration: sshd -t;
• Restart sshd;
• Verify the result: sshd -T | grep -i passwordauthentication should output passwordauthentication no.

To detect possible compromise, the Alpine advisory recommends checking /var/log/messages for Accepted password for entries for accounts without a password — such as alpine, root, or accounts that are supposed to use keys only. On potentially compromised machines you should also review doas usage, recently created users, files and authorized keys. As the advisory states: “If you cannot rule out that a login occurred, assume the machine is compromised.”

Alpine Linux administrators with SSH access enabled should prioritize updating packages and restarting sshd on tiny-cloud cloud instances running versions 3.18.11–3.24.3, where the combination of this vulnerability with doas rights provides a direct path to root. On all other affected systems, update priority is determined by the presence of the four conditions described — if even one of them is not met, the system is not vulnerable to this attack.