Alpine Linux SSH vulnerability allows passwordless login via long strings

Alpine Linux has issued an urgent security advisory for a severe vulnerability in its OpenSSH server implementation. The flaw allows remote attackers to bypass password authentication entirely and gain shell access to affected systems without knowing any credentials. Administrators running Alpine versions 3.16 through 3.24 must update their openssh packages and restart the SSH daemon immediately to close this exposure.

What happened

The vulnerability affects the sshd daemon when it is built without Pluggable Authentication Modules (PAM), which is the default configuration for the standard Alpine openssh-server package. An attacker who can reach the SSH port can log in as any user account that has no password set, provided the system has at least one other local account with a standard password hash. The attack requires only a single connection attempt and succeeds reliably without retries or brute-force techniques.

This issue impacts a wide range of Alpine releases, including supported versions 3.21 through 3.24 and older unsupported versions back to 3.16. It specifically targets systems where PasswordAuthentication is enabled, which remains the OpenSSH default unless explicitly disabled. Common scenarios include root accounts configured with PermitRootLogin yes, key-only users created without passwords, and users managed via directory services like SSSD or Winbind that lack local shadow entries.

Official tiny-cloud images are particularly vulnerable if they have been modified after initial boot. While these images ship with safe defaults, adding any user with a password hash or setting a console password introduces the necessary condition for the exploit. Once triggered, an attacker can log in as the default alpine user and escalate privileges to root using doas, which is configured for passwordless use in these environments.

How it works

The root cause lies in how OpenSSH handles password verification when compiled without PAM support. In this mode, sshd uses the C library function crypt() to hash the provided password and compare it against the stored hash in /etc/shadow. For accounts with no password, the stored field contains a single asterisk (*). Normally, crypt() requires a salt from the stored hash to process the input, but accounts with * have no salt.

When encountering such an account, sshd borrows the salt from another account on the system that does have a valid $5$ or $6$ hash. The vulnerability triggers when the attacker sends a password string between 257 and 1024 bytes long. The musl C library, used by Alpine, returns * as an error indicator when processing keys longer than 256 bytes. Since the stored field for the target account is also *, the comparison matches, and authentication succeeds.

Key details

• Affected versions: Alpine 3.16 through 3.24, including edge and unsupported releases.
• Prerequisites: sshd built without PAM (or UsePAM no), PasswordAuthentication yes, and at least one account with a $5$ or $6$ hash.
• Target accounts: Users with * in the password field, such as key-only users or the default alpine user.
• Fixed packages: Available for all branches, including 9.9_p2-r1 for 3.21 and 10.6_p2-r0 for edge.
• Detection: Check /var/log/messages for Accepted password for entries linked to accounts with no password.
• Cloud risk: Tiny-cloud images become exploitable if any password hash is added post-boot.

Why it matters

For infrastructure engineers and DevOps teams, this vulnerability undermines the fundamental assumption that SSH key-only accounts are secure against password-based attacks. Many organizations rely on Alpine for containers and lightweight VMs, often assuming that disabling root password login is sufficient. However, this bug bypasses those protections by exploiting the interaction between empty password fields and the presence of other hashed passwords on the system. It highlights the risks of default configurations in minimal distributions where PAM is not used.

The ease of exploitation makes this particularly dangerous. Unlike brute-force attacks that generate noise and can be blocked by fail2ban, this method requires only one packet and leaves no immediate trace of failed attempts. If an attacker gains access to a cloud instance, they can quickly escalate privileges and pivot within the network. Teams must verify not just that they have updated packages, but that the running daemon has actually been restarted, as package managers do not always restart services automatically.

What you can do

• Update your system immediately using apk upgrade -U -a and ensure you install the fixed version for your branch.
• Restart the SSH daemon explicitly with rc-service sshd restart after upgrading, as the update alone does not reload the running process.
• If you cannot update immediately, disable password authentication by setting PasswordAuthentication no in your SSH config and restarting the service.
• Verify your configuration with sshd -T | grep -i passwordauthentication to ensure the change is active.
• Audit your logs for unexpected Accepted password entries for accounts that should not have passwords.
• Review cloud instances for any added user password hashes that might have inadvertently enabled the vulnerability.