Security Intelligence
Loading table of contents...
Loading table of contents...
At a glance:
-
OpenSSH released Portable OpenSSH 10.6p2 on November 5, 2026, to address CVE-2026-123158, a password authentication bypass with a CVSS 3.1 score of 8.1 (High) that affects Alpine Linux and other systems built on the musl C library.
-
The vulnerability allows a remote threat actor to log in to accounts that have no password set, including Secure Shell (SSH) key-only accounts, by sending a password between 257 and 1,024 bytes long in a single attempt.
-
Exposure depends on deployment and configuration: the OpenSSH server checks passwords directly instead of through Pluggable Authentication Modules (PAM), password authentication is enabled (the OpenSSH default), and the target account and at least one other local account meet specific password-field conditions.
Threat summary
On November 5, 2026, OpenSSH released version 10.6p2 to address an authentication bypass vulnerability affecting certain deployments of Alpine Linux.
The issue became public alongside technical research and proof-of-concept material demonstrating that a remote threat actor could authenticate to accounts configured without passwords by submitting an unusually long password during Secure Shell (SSH) authentication. No exploitation activity had been reported at the time of disclosure.
SSH is a remote administration protocol widely used to manage Linux and Unix systems. The vulnerable functionality exists within the OpenSSH server process (sshd) when it validates passwords on systems that use the musl C library and do not use Pluggable Authentication Modules (PAM). In these environments, sshd performs password verification directly through musl’s crypt() function.
The vulnerability, tracked as CVE-2026-123158, is rated with CVSS 8.1 or High severity. It occurs when musl processes passwords longer than 256 bytes. Under specific conditions, crypt() returns an asterisk (*) value indicating an error. For accounts that are configured without passwords and therefore also use an asterisk in the password field, sshd can incorrectly interpret the result as a successful authentication and grant access.
Exploitation requires several conditions:
-
The system must run OpenSSH without PAM
-
Password authentication must be enabled
-
The target account must be configured without a password
-
At least one local account must use SHA-256 ($5$) or SHA-512 ($6$) password hashes
-
The threat actor has network access to the SSH service and knowledge of a valid username
No user interaction is required. When these conditions exist, a single SSH connection using a password between 257 and 1,024 bytes is sufficient to authenticate successfully.
Researchers highlighted a scenario involving Alpine tiny-cloud images where an adversary could authenticate as the alpine user and then use passwordless doas to obtain root privileges, resulting in full control of the host.
Alpine Linux identified releases 3.16 through 3.24 and edge as affected. Other musl-based platforms running OpenSSH, including systems built with Buildroot or Yocto, and OpenWrt deployments that use OpenSSH instead of the default Dropbear server, may be in scope. Systems using glibc, deployments where PAM handles password validation, Dropbear-based SSH services, locked accounts marked with an exclamation mark (!), and containers that do not run sshd are not affected.
While the default PermitRootLogin prohibit-password setting protects direct SSH access to root, any exposed account with doas privileges can provide a path to root-level access. Alpine tiny-cloud images from 3.18.11 through 3.24.3 include this alpine account with an asterisk password field. These images become vulnerable once a compatible password hash exists on the system, such as after an administrator configures a console password.
On November 1, 2026, Alpine 3.21 reached end of support, and Alpine still published fixes for it and for releases 3.16 to 3.20. The flaw traces back to an OpenSSH timing fix in 2016 (CVE-2016-6210) and two musl changes in August 2012 that made crypt() return an asterisk on error and capped SHA-512 input at 256 bytes.
Analysis
The organizations most exposed are those that use Alpine Linux as the operating system for internet-facing servers, cloud workloads, security appliances, container hosts, or embedded platforms while relying on the standard OpenSSH server package. Other musl-based environments may also warrant review where OpenSSH is deployed.
The vulnerability is attractive because SSH commonly provides direct access to production infrastructure. A successful login bypasses the need to steal credentials, compromise SSH keys, or exploit additional vulnerabilities. Once authenticated, a threat actor operates using a legitimate account and can interact with the system through normal administrative channels.
The confirmed impact is unauthorized access to vulnerable accounts configured without passwords. The downstream impact depends on the permissions associated with those accounts. In environments where the exposed account has administrative privileges, privileged command execution capabilities, or access to automation workflows, unauthorized access can extend beyond the initial SSH session.
Operationally, the greatest risk exists in environments where SSH is exposed to the internet and key-only accounts are trusted as the primary administrative control. Security teams may not expect password-based authentication attempts to succeed against those accounts, which can reduce the likelihood that suspicious logins receive immediate scrutiny.
Mitigations
Upgrade affected systems to OpenSSH 10.6p2 or the corresponding fixed packages provided by Alpine Linux. The update removes the vulnerable authentication path and prevents successful exploitation of the flaw. Systems running Alpine Linux require both a package update and an SSH service restart for the fix to take effect.
Review SSH configurations and identify systems where password authentication remains enabled. Disabling password authentication removes the vulnerable code path and limits access to approved authentication mechanisms such as SSH keys.
Identify accounts configured without passwords, including key-only administrative accounts and service accounts. Reviewing these accounts helps determine whether vulnerable conditions are present and highlights systems requiring priority remediation.
Monitor SSH authentication logs for successful password logins involving accounts intended for key-only access. Reviewing privileged activity, account creation events, authorization changes, and doas usage can help identify signs of unauthorized access on systems that were exposed before remediation.
Stay on top of emerging threats like this.
Sign up to receive a weekly roundup of our security intelligence feed. You'll be the first to know of emerging attack vectors, threats, and vulnerabilities.
