THREAT BRIEFING · 13.11.2026 DEENFRES

News

OpenSSH Flaw Enables Login Bypass on Alpine Linux

By Alec Chizhik · November 6, 2026 · 5 min read

OpenSSH 10.6p2 fixes a login bypass in the SSH server on musl-based systems such as Alpine Linux. The flaw affects servers running without PAM that allow password logins and have a specific account configuration. After updating, an explicit restart of sshd is required – the version number alone is not a reliable indicator of protection.

Key Takeaways

  • OpenSSH 10.6p2 fixes a login bypass on musl systems. Older versions with UsePAM=no and PasswordAuthentication=yes are affected.
  • On Alpine, the account setup determines exposure. Required: a target account with * in the password field, plus another local account with a SHA-256 or SHA-512 password hash.
  • Updating requires a restart of sshd. Patched Alpine packages keep older version numbers, so the identifier alone does not reliably reveal the vulnerability.

Related: Oracle patches 1,209 vulnerabilities with 112 critical fixes

A Flaw with Preconditions

Administrators typically use an SSH server to access remote Linux machines. Since 5 November, it has been clear that certain systems can be accessed without a valid password. OpenSSH 10.6p2 blocks this login bypass in the SSH server. Affected are OpenSSH versions prior to 10.6p2 built on musl, provided the server runs with UsePAM=no and PasswordAuthentication=yes.

musl is a compact C standard library – the foundational layer through which programs on Linux invoke basic functions. Alpine Linux is built on musl. PAM stands for Pluggable Authentication Modules and governs login through interchangeable modules. Whether a machine is vulnerable therefore depends on its configuration and account setup.

What is PAM? PAM stands for Pluggable Authentication Modules, an interface through which Linux services hand off logins to interchangeable modules. An SSH server thus does not have to perform password verification itself. On Alpine, OpenSSH with PAM support ships in the openssh-server-pam package and uses PAM with the setting UsePAM yes.

Accounts with an Asterisk in the Password Field

On Alpine systems, the flaw only comes into play when several conditions coincide. SSH runs without PAM and permits password logins. The target account has an asterisk * in the password field, meaning it has no usable password. Another local account holds a password hash created with the SHA-256 or SHA-512 method. Under these conditions, the examined Alpine versions 3.16 through 3.24 are affected, as is the development branch edge.

In its own tests, Check Point found that the attack additionally required an active account with a real password. A stored password hash alone was not sufficient there. Systems that use the openssh-server-pam package with UsePAM set to yes are excluded.

From Cloud Image to Root

A complete attack chain affects images with tiny-cloud, the tool that sets up Alpine instances in the cloud at boot. If a SHA-512 password hash has been created on an affected image, login as the user alpine succeeds. From there, passwordless doas leads to root privileges. doas is a compact alternative to sudo that allows users to execute commands with elevated privileges. The login bypass can therefore give an attacker full control over the instance.

The Version Number Doesn’t Reveal the Patch Status

Anyone checking their own systems will run into an inventory problem: patched Alpine packages keep their older OpenSSH version numbers. On Alpine 3.24, for example, the corrected package carries the identifier 10.3_p1-r2. The version string alone therefore gives no reliable indication of whether a system is vulnerable.

A query that only searches for OpenSSH 10.6p2 will fall short on Alpine. A dependable check requires looking at the package revision, the sshd configuration, and the password fields of local accounts together.

Immediate Actions for Operators

Affected operators should update OpenSSH and then explicitly restart sshd. Where an update is not immediately possible, they should set PasswordAuthentication no and also restart sshd. This disables password logins on the SSH server.

In addition, operators should look back: search the system log /var/log/messages for password logins to passwordless accounts. If such a login cannot be ruled out, the machine must be treated as compromised.

Frequently Asked Questions

Every question is locked. A tap unlocks the answer.

Is Dropbear also affected?

No. The login bypass affects OpenSSH. Dropbear, a compact alternative SSH server, is unaffected, as is other software outside OpenSSH that uses password-based logins. 

Are containers at risk?

Containers without a running sshd are excluded. The first step in assessing a container is therefore to check whether an SSH server is running inside it.

Is there a CVE identifier?

According to GitHub, the flaw is registered as CVE-2026-123158. The advisory entry dates from 5 November and is marked as unreviewed. It describes the login bypass in OpenSSH versions before 10.6p2 on Linux systems with musl and without PAM.

Image source: AI-generated (November 2026)

Translated from the German original using artificial intelligence. The German version is authoritative.

Further reading

A magazine by Evernine Media GmbH