OpenSSH Password Authentication Bypass Exposes Alpine Linux Servers to Unauthorised Access

A security vulnerability in OpenSSH could allow remote attackers to bypass password authentication on certain Alpine Linux systems, potentially granting access to accounts that are intentionally configured without passwords.

Alpine Linux disclosed the issue on 5 November 2026 in a security advisory titled openssh-server password authentication bypass. The vulnerability affects specific configurations involving OpenSSH, the musl C library and disabled PAM authentication.

The vulnerability is particularly concerning because accounts designed for SSH key-based authentication may become accessible through password authentication under the affected conditions.

Alpine Linux has released patched packages across affected release branches and recommends that administrators update OpenSSH and restart the SSH daemon. Simply installing the updated package does not replace an already running vulnerable SSH process.

Understanding the OpenSSH Authentication Bypass

OpenSSH is widely used to establish encrypted remote connections to Linux servers and infrastructure. Its SSH daemon, sshd, handles incoming connection requests and verifies user authentication.

The vulnerability occurs when OpenSSH runs without PAM authentication on systems using musl libc.

Under certain account configurations, an attacker who can reach the SSH service may submit an unusually long password and successfully authenticate to an account that should not accept password-based login.

The attack requires several conditions to be present simultaneously:

• The system uses OpenSSH with musl libc.

• PAM authentication is disabled.

• SSH password authentication is enabled.

• A target account has * in its password field.

• At least one other local account has a SHA-256 ($5$) or SHA-512 ($6$) password hash.

• The attacker can reach the SSH service.

Alpine Linux reports that an attacker can use a password between 257 and 1,024 bytes to exploit the issue when these conditions are met.

How the Vulnerability Works

The security issue originates from an interaction between OpenSSH's password verification process and the musl C library's crypt() function.

Normally, when SSH password authentication is used, the submitted password is processed and compared with the stored password hash.

However, the affected authentication implementation encounters an unexpected condition when processing accounts whose password field contains an asterisk (*).

This character is commonly used in Linux password databases to represent accounts without a usable password.

The vulnerability involves the following sequence:

1. Target account configuration: An account has * in its password field, indicating that it does not have a usable password for conventional password authentication.

2. Salt selection: When the account's stored password field does not contain a usable hash salt, the affected SSH authentication process borrows the salt from another account.

3. Long password submission: An attacker submits a password exceeding 256 bytes.

4. Library error handling: The musl crypt() function returns * as an error indicator when the submitted password exceeds its supported length.

5. Authentication comparison: The returned error indicator matches the target account's stored * value.

6. Authentication bypass: The comparison succeeds, allowing access to the account without knowing its actual password.

This behaviour creates an authentication failure because an error indicator is interpreted as a matching password value.

Which Alpine Linux Systems Are Affected?

According to Alpine Linux, the vulnerability affects its openssh-server package because it is built without PAM authentication.

The openssh-server-pam package is also affected when configured with UsePAM no. Systems using openssh-server-pam with UsePAM yes are not affected by this issue.

The advisory identifies affected Alpine releases from 3.16 through 3.24, including the edge branch.

The fixed packages are also included in the respective updated Alpine releases: 3.21.10, 3.22.8, 3.23.8 and 3.24.4.

Important: The vulnerability is not limited to the latest Alpine release. Administrators operating older supported or legacy environments should also investigate their installations.

Systems and Configurations Not Affected

Alpine Linux identifies several configurations that are not vulnerable to this specific issue:

• Systems configured with PasswordAuthentication no.

• Systems using openssh-server-pam with UsePAM yes.

• Systems where no account contains a SHA-256 or SHA-512 password hash.

• Accounts whose password field begins with !, which are locked.

• Docker containers and other container environments that do not run an SSH daemon.

• Cloud images configured through cloud-init with password authentication disabled.

These distinctions are important because installing Alpine Linux or using an Alpine-based container does not automatically mean a system is vulnerable. The relevant authentication configuration and account conditions must also be present.

Security Implications for Alpine Cloud Images

The advisory also highlights a potential exposure involving Alpine's official tiny-cloud images.

Certain official cloud image releases from Alpine 3.18.11 through 3.24.3 include an alpine account with a * password field and passwordless doas access.

These images are safe on first boot under the conditions described by Alpine. However, they can become exploitable when a SHA-512 password hash is introduced, for example, when an administrator sets a console password or cloud user data creates an account with a hashed password.

If an attacker successfully authenticates as the alpine user, passwordless doas could allow the attacker to obtain root privileges.

Alpine states that images built from versions 3.21.10, 3.22.8, 3.23.8, 3.24.4 and later include the fixed package.

Administrators should therefore inspect already-running cloud instances rather than assuming that an image was safe when it was initially deployed.

How Administrators Can Fix the Vulnerability

Alpine Linux recommends upgrading the OpenSSH package as the primary remediation.

Step 1: Upgrade Alpine packages

Run the following command with root privileges:

apk upgrade -U -a

This updates installed packages using the available Alpine repositories.

Step 2: Restart the SSH service

After the upgrade, restart the SSH daemon:

rc-service sshd restart

This step is essential because updating the package alone does not replace the already running vulnerable SSH daemon.

Step 3: Verify the running configuration

Administrators can inspect the effective SSH password authentication setting using:

sshd -T | grep -i passwordauthentication

If the temporary mitigation has been applied, the expected output is:

passwordauthentication no

Alternative mitigation: Disable password authentication

If an immediate package upgrade is not possible, administrators should disable password-based SSH authentication:

PasswordAuthentication no

Before making this change, administrators should verify that SSH key-based access works and retain their existing administrative session until a new connection has been successfully tested.

Disabling password authentication prevents exploitation through this particular password authentication bypass, although it does not replace the security update.

How to Investigate Potential Exploitation

Administrators should also investigate whether exposed systems have already been accessed.

Alpine Linux recommends reviewing /var/log/messages for SSH authentication entries such as:

Accepted password for

Pay particular attention to successful password logins involving accounts that are intended to be passwordless, including alpine, root and key-only user accounts.

Additional investigation should include:

• Reviewing unexpected doas activity.

• Checking for recently created user accounts.

• Inspecting changes to SSH authorized_keys files.

• Reviewing unexpected files and administrative activity.

• Investigating successful password logins that should not have been possible.

If administrators cannot rule out unauthorised access, Alpine recommends treating the affected machine as compromised.

Broader Security Implications for Linux Infrastructure

The OpenSSH vulnerability highlights how interactions between authentication software and underlying system libraries can introduce security weaknesses even when individual components are performing their intended functions.

For organisations using Alpine Linux in cloud infrastructure, embedded systems, servers and lightweight deployments, the advisory reinforces the importance of validating authentication configurations across the entire environment.

It also demonstrates why security teams should not rely exclusively on package installation status. A successful upgrade must be followed by service restarts and configuration verification.

Industry analysis: The development highlights a broader cybersecurity challenge involving software dependencies and authentication boundaries. Security teams should consider auditing SSH configurations, account states and library dependencies as part of their vulnerability management processes.

For organisations operating large Linux fleets, identifying systems that run SSH services and prioritising those with exposed password authentication can help accelerate remediation.