OpenSSH Authentication Bypass: A Crafted Password Could Grant Unauthorised SSH Access

Overview:

What Is the OpenSSH Authentication Bypass Vulnerability?

A server's password authentication mechanism is expected to be one of its first lines of defence. However, a newly disclosed OpenSSH authentication bypass vulnerability could allow attackers to gain access to certain Linux servers without knowing the account's password.

Disclosed on 5 November 2026, the vulnerability affects specific OpenSSH configurations, particularly Alpine Linux systems using the musl C library. It exploits an error-handling weakness during password verification, allowing specially crafted passwords between 257 and 1,024 bytes to be incorrectly accepted for certain accounts configured without passwords.

This means an attacker with network access to a vulnerable SSH service and knowledge of a susceptible account name could potentially authenticate without valid credentials. In some configurations, the compromised account could also provide a pathway to elevated privileges.

OpenSSH has rated the flaw critical and released version 10.6p2 to address the issue. Alpine Linux has also published security updates for affected distribution releases, including older versions.

Who Is Affected

The vulnerability primarily affects Alpine Linux deployments running OpenSSH without PAM-based authentication. However, other Linux environments built around the musl C library should also be assessed.

A system is potentially vulnerable when all the following conditions are present:

• It runs Alpine's standard openssh-server package or openssh-server-pam with UsePAM no.

• SSH password authentication is enabled (PasswordAuthentication yes).

• At least one local account has * in its password field, indicating that no password is configured.

• At least one other local account has a password hash beginning with $5$ or $6$.

The attacker must also know the username of an affected passwordless account.

Other environments to review:

• OpenWrt systems where OpenSSH has been installed instead of the default Dropbear SSH server.

• Buildroot-based deployments.

• Yocto-based Linux environments.

Systems not affected by this specific vulnerability include:

• Linux systems using glibc.

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

• Systems where SSH password authentication is disabled.

• Containers that do not run the SSH daemon.

• Systems without the affected passwordless account and password-hash combination.

How Does the Vulnerability Work?

The weakness originates from how OpenSSH interacts with the musl C library during password verification.

When an SSH server verifies a password without PAM, it uses the crypt() function to process the submitted password and compare the resulting hash against the account's stored password information.

However, when musl encounters passwords exceeding 256 bytes, it returns an asterisk (*) as an error indicator. This creates a security issue because an account without a configured password may also have * stored in its password field.

Under the vulnerable conditions, the returned error value can match the stored password field, causing the authentication check to succeed when it should have failed.

Consequently, an attacker can exploit this behaviour by submitting a specially crafted long password, potentially gaining access to an account without possessing its legitimate credentials.

4. Potential Security Impact

Successful exploitation could expose organisations to several security risks:

• Unauthorised Access: Attackers could gain access to affected SSH accounts without valid passwords.

• Privilege Escalation: Accounts with administrative privileges or access to privilege-escalation utilities such as doas could provide a pathway to root-level access.

• Credential and Data Exposure: Once inside a compromised server, attackers could access sensitive files, application data and other stored credentials.

• Persistence: Attackers could create unauthorised accounts, modify SSH authorised keys or introduce other mechanisms to maintain access.

• Lateral Movement: A compromised Linux server could become an entry point for accessing additional systems within an organisation's network.

Recommendations

Organisations should prioritise identifying affected systems and applying the available security updates.

1. Identify potentially affected systems

Review Linux servers, cloud instances and virtual machines running OpenSSH, paying particular attention to Alpine Linux and other musl-based distributions.

2. Apply security updates

Upgrade affected OpenSSH installations to version 10.6p2 or later. Alpine Linux administrators should apply the appropriate security updates for their distribution version.

3. Disable password-based SSH authentication

Where immediate patching is not possible, disable password authentication as a temporary mitigation, provided SSH key-based access has been configured and tested.

Set the following in the SSH server configuration:

PasswordAuthentication no

4. Restart the SSH service

After applying updates or configuration changes, restart the SSH daemon to ensure the changes take effect.

For Alpine Linux:

apk upgrade -U -a

rc-service sshd restart

5. Review authentication logs

Investigate unusual SSH authentication activity, particularly unexpected successful logins involving accounts configured for key-only access.

6. Investigate privileged account activity

Review recent account changes, authorised SSH keys, administrative commands and other activities that could indicate unauthorised access.

If unauthorised access cannot be ruled out, treat the affected system as potentially compromised and initiate incident response procedures.

This vulnerability highlights how weaknesses in underlying system libraries can undermine otherwise trusted authentication mechanisms. Organisations should maintain visibility into their external attack surface, monitor exposed SSH services and prioritise vulnerability remediation to reduce the risk of unauthorised access and infrastructure compromise.