Critical OpenSSH flaw on Alpine Linux allows login with long passwords

A critical vulnerability in OpenSSH allows attackers to bypass authentication on specific Alpine Linux configurations by submitting excessively long passwords. The OpenSSH project released version 10.6p2 on November 5, 2026, to address the issue, while Alpine Linux has backported fixes to all supported releases.

What happened

Attackers with network access can log into user accounts that have no password set, such as SSH key-only users or the default alpine user in cloud images. To succeed, the attacker needs the account name and must supply a password between 257 and 1,024 bytes long. This flaw specifically affects systems running the standard openssh-server package on Alpine Linux, which is built without the Pluggable Authentication Module (PAM) interface.

The vulnerability arises from an interaction between OpenSSH’s password checking logic and musl, the C library used by Alpine. When password authentication is enabled and at least one other local account has a password hash, the server incorrectly accepts the long password for any account with an empty password field. Although no active exploits have been reported, the OpenSSH team rated the flaw critical and urged immediate mitigation.

Damien Miller of the OpenSSH project emphasized the urgency, stating that administrators should "set PasswordAuthentication=no or disable SSH for these systems IMMEDIATELY." The fix was released rapidly, with Miller noting that long embargoes are increasingly dangerous as AI agents can rediscover such bugs within hours.

How it works

The root cause lies in how sshd handles password verification when PAM is not in use. Normally, sshd hashes the provided password using the crypt() function and compares it to the stored hash in /etc/shadow. Accounts with no password have a * character in this field. Because * is too short to contain a salt, sshd borrows the salt from another account that does have a password hash.

When an attacker submits a password longer than 256 bytes, musl’s crypt() function refuses to process it and returns * to signal an error. Since the stored field for the target account is also *, the comparison succeeds, and the server grants access. This behavior stems from a 2012 change in musl designed to prevent crashes in programs that did not check for crypt() failures, combined with a 2016 OpenSSH change intended to prevent username enumeration.

The new version, 10.6p2, introduces a workaround that rejects any match if the stored password field is shorter than four characters. While this stops the attack, the OpenSSH team notes that the underlying issue resides in the C library’s handling of long inputs rather than in SSH itself.

Key details

• Affected systems: Alpine Linux running openssh-server without PAM, or openssh-server-pam with UsePAM no.
• Prerequisites: PasswordAuthentication must be yes, at least one account must have a $5$ or $6$ hash, and the target account must have * in its password field.
• Attack vector: A single connection attempt with a password between 257 and 1,024 bytes succeeds every time.
• High-risk targets: The alpine user in tiny-cloud images (versions 3.18.11 through 3.24.3) is vulnerable once any password hash exists on the system, potentially allowing root access via doas.
• Unaffected systems: Linux distributions using glibc, systems using PAM for authentication, and OpenWrt devices using Dropbear.
• Fix availability: OpenSSH 10.6p2 is available now; Alpine has updated packages for versions 3.16 through 3.24.

Why it matters

For engineers building infrastructure on Alpine Linux, this vulnerability undermines the security of key-only authentication setups. Many developers rely on Alpine for its small footprint in containers and cloud instances, often assuming that disabling password logins or using SSH keys provides sufficient protection. However, because PasswordAuthentication is enabled by default in many configurations, these systems remain exposed until explicitly hardened.

The incident also highlights the growing pressure on open-source maintainers to release patches quickly. The decision to skip a traditional embargo reflects a shifting threat landscape where automated tools can reverse-engineer vulnerabilities rapidly. Teams must now prioritize rapid patching cycles and assume that technical details of critical flaws may become public knowledge almost immediately after discovery.

What you can do

• Update your Alpine packages immediately using apk upgrade -U -a and restart the SSH service with rc-service sshd restart.
• If you cannot update right away, disable password authentication by setting PasswordAuthentication no in your SSH configuration.
• Verify your configuration changes by running sshd -T | grep -i passwordauthentication to ensure it returns no.
• Check /var/log/messages for entries showing Accepted password for users like root or alpine who should not have password access.
• Review doas usage and recently created users on any potentially exposed machines, treating them as compromised if suspicious activity is found.
• Audit other musl-based systems like Buildroot or Yocto if they run OpenSSH, though OpenWrt is generally safe if using Dropbear.