Collaboration

OpenSSH Long-Password Vulnerability (CVE-2026-123158): Impact and Fixes

Ray/2026.11.06

OpenSSH released version 10.6p2 on November 5, 2026, to address a password authentication bypass that can be triggered through SSH. The issue affects certain Linux configurations that use musl libc and perform password authentication without PAM. OpenSSH describes the release as containing a critical security workaround. Organizations using Alpine Linux or devices built with musl should prioritize checking whether they run an affected SSH service. The issue was reported by Özgün Kültekin of Wakefield.[1]

Known as sshhole, the issue is now tracked as CVE-2026-123158. Some early advisories still state that no CVE had been assigned, reflecting their publication timing. The important distinction is how authentication actually works: a long password does not grant access to every OpenSSH server or every account, and routinely using SSH keys does not establish that password authentication has been disabled.[2][3][4]

Conditions required for exploitation

On an unpatched system, an attacker must be able to reach the SSH service and know the target account name. The following conditions must also be met:[3][4]

The system running OpenSSH sshd uses musl libc, and authentication does not pass through PAM. This includes builds without PAM support and PAM-capable builds configured with UsePAM no.
The effective configuration for the connection permits PasswordAuthentication yes.
The target account’s password field contains a single asterisk (*), and other access controls permit the account to log in.
Another local account has a password hash beginning with $5$ or $6$, providing hash parameters that the authentication code can select.

According to Alpine’s advisory, passwords between 257 and 1,024 bytes can trigger the bypass under these conditions. The length is measured in bytes, not characters, and the target account’s * marker is not an empty password.[4] If AuthenticationMethods requires multiple authentication methods, an attacker must still satisfy the other requirements. The flaw does not imply that every authentication factor can be bypassed.[9]

The OpenSSH maintainer states that Linux systems using glibc, non-Linux systems, and systems that use PAM for password authentication are not affected by this vulnerability. Asset reviews should therefore examine the libraries and configuration actually used by sshd, rather than flagging every Linux or OpenSSH installation as vulnerable.[5]

Why a long password can be accepted

When PAM is not used, sshd passes the supplied password to crypt() and compares the result with the account’s stored password field. If that field contains only *, it is too short to supply normal hash parameters, so the code borrows parameters from another account. This behavior is associated with an earlier change intended to reduce timing differences that could reveal whether an account exists.[3]

The relevant SHA-crypt implementations in musl reject excessively long input. In the SHA-512 crypt implementation, for example, a password longer than 256 bytes causes the operation to fail and return * as an error indicator. When that value matches the * stored for the target account, the older authentication logic can mistake a failed operation for a matching password.[6][7]

The failure occurs when an error indicator is compared with an account marker. It does not mean that SSH encryption or a user’s private key has been broken. The OpenSSH patch adds a minimum-length check for the stored password hash, preventing short markers of this kind from being accepted as valid hash matches. The remedy is not to shorten users’ passwords.[7]

Distinguishing key-based access from password policy and root access

An account without a usable password hash and a server that prohibits the password authentication method represent different controls. An effective PasswordAuthentication no setting blocks this vulnerability, and the musl maintainer recommends it when an immediate update is not possible. Describing this incident as a bypass that works even after password authentication has been disabled would therefore be misleading.[8]

Likewise, gaining access to an account does not automatically mean gaining root access. The default PermitRootLogin prohibit-password setting disables password and keyboard-interactive authentication for root, but it does not remove administrative privileges already granted to other accounts.[9]

Alpine notes that some older tiny-cloud images give the alpine account passwordless doas privileges. If a qualifying password hash is later added to the host, an attacker may be able to log in to that account and then become root. Alpine containers that do not run sshd are not exposed through this SSH attack path.[4]

Verify that updates and configuration changes take effect

Organizations should prioritize the patched packages supplied by their Linux distribution or device vendor. Upstream OpenSSH 10.6p2 includes the workaround. Alpine has also released updates including 3.21.10, 3.22.8, 3.23.8, and 3.24.4, and has backported the fix to stable-branch packages. An upstream version number below 10.6p2 is therefore not sufficient evidence that a system remains unpatched. Check the complete package version against the vendor’s advisory.[1][4][10]

On Alpine, sshd must be restarted after the package update. Installing a new package does not replace the daemon that is already running. Systems managed by OpenRC can use rc-service sshd restart, as described in the official advisory.[4]

If an immediate update is not possible, first confirm that SSH key authentication works and keep the existing administrative session open. Then set PasswordAuthentication to no. After checking the configuration and restarting the service, establish a new connection to verify that administrative access still works.[8]

Use sshd -t to validate the configuration and sshd -T to inspect its effective settings. If Match blocks are present, use -C with the actual account, source address, and other relevant connection conditions. If the service uses a custom configuration file or startup options, include those conditions in the check as well. Finding a PasswordAuthentication no line in a configuration file does not establish that the value applies to every connection.[9][11]

Investigate unexpected successful logins

Alpine recommends checking /var/log/messages for Accepted password for entries, especially for accounts that should not have a usable password. Review doas activity, newly created accounts, and changes to authorized_keys as well.[4]

RayAegis recommends correlating successful login events with the account’s state at the time, the source address, and known administrative activity, rather than looking only for large numbers of failed attempts. If an unauthorized login is identified, preserve the logs, restrict connectivity to the affected host, and investigate credentials, persistence mechanisms, and access to internal systems. Updating a package alone cannot undo actions an attacker may already have taken.

This incident reinforces the need to include running services, operating system libraries, authentication settings, and account privileges in SSH security reviews. RayAegis recommends verifying the effective state after each remediation and limiting administrative services to necessary sources, so that asset inventories and configuration baselines reflect the environment that is actually accessible.