CVE-2026-123158: OpenSSH Password Authentication Bypass Affects Alpine Linux

A high-severity vulnerability in OpenSSH can allow unauthenticated remote attackers to bypass password authentication on certain Linux systems by submitting an overlong password. Tracked as CVE-2026-123158 and dubbed SSHhole, the flaw carries a CVSS 3.1 score of 8.1 and primarily impacts Linux environments where sshd is linked against musl libc and operates without PAM. Alpine Linux is the most prominent affected platform because its standard openssh-server package uses this configuration by default.

The vulnerability results from an unexpected interaction between OpenSSH password validation and musl libc’s crypt() implementation. When an excessively long password is supplied, crypt() can return the string * to indicate an error. Some Linux accounts that are configured without a conventional password also store * in the password field of /etc/shadow. Under vulnerable conditions, sshd can incorrectly interpret the matching values as successful authentication.

An attacker does not need to know the target user’s password. If an exposed SSH service meets the required conditions, an attacker who can reach the service can authenticate to certain accounts using a password in the vulnerable length range. The impact depends on the privileges assigned to the compromised account. Access to a privileged service account or an account capable of using doas or another privilege escalation mechanism could lead to full system compromise.

Contact Sales

OpenSSH addressed the issue in Portable OpenSSH 10.6p2, released on November 5, 2026. Alpine Linux simultaneously released patched OpenSSH packages for all supported branches and several older branches. The OpenSSH team describes the release as containing a critical security workaround for Linux systems using musl libc with PAM disabled.

Public reproduction environments and proof-of-concept material are already available. However, as of November 6, 2026, the reviewed sources do not report confirmed exploitation of the vulnerability in real-world attacks, and the flaw has not been added to CISA’s Known Exploited Vulnerabilities catalog.

Organizations can strengthen defenses against emerging authentication bypass vulnerabilities with SOC Prime’s AI-Native Detection Intelligence Platform, accelerating threat hunting and detection engineering across SIEM, EDR, XDR, and Data Lake environments.

Security teams can also use Prime Architect to transform vulnerability intelligence into hunting queries and detection logic tailored to their available SSH, authentication, endpoint, and network telemetry.

Detect CVE-2026-123158 by monitoring successful password-based SSH logins to accounts that normally use key-only authentication, unusual authentication attempts containing abnormally long passwords, unexpected remote access to service accounts, and post-authentication activity inconsistent with the account’s normal behavior.

Detection content may not be available for every CVE. Check the SOC Prime Platform for current coverage. If relevant detections are not yet available, check again as new threat intelligence and detection content are continuously added.

CVE-2026-123158 analysis

CVE-2026-123158 affects OpenSSH sshd before Portable OpenSSH 10.6p2 when it runs on Linux with musl libc and password authentication occurs without PAM. The CVE carries a CVSS 3.1 score of 8.1 with the vector AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H, reflecting remote exploitation without prior privileges or user interaction but requiring a specific system and account configuration.

The root cause lies in the interaction between OpenSSH and the password hashing function provided by musl libc.

On systems where PAM is disabled, sshd performs password validation using the system’s crypt() functionality. For a typical account, /etc/shadow contains a cryptographic password hash, and the value generated from the user’s submitted password is compared against that stored hash.

musl libc behaves differently when the supplied password exceeds its supported input length. For passwords longer than 256 bytes, crypt() returns * as an error value rather than a normal password hash.

The problem arises because * is also commonly used in /etc/shadow for accounts that do not have a traditional password configured.

If a vulnerable sshd receives an overlong password for one of these accounts, the authentication flow can effectively compare the * returned by crypt() with the * stored in the account’s shadow entry. The values match, and authentication can incorrectly succeed.

The CVE description states that, for affected account configurations, passwords between 256 and 1024 characters can result in successful authentication. Independent reproductions describe passwords exceeding the normal 256-byte boundary as sufficient to trigger the vulnerable condition.

The flaw is therefore not a universal password bypass affecting every OpenSSH deployment.

Several specific conditions must align.

First, the server must use musl libc. Alpine Linux is the primary mainstream example, although other embedded or minimal Linux environments can also use musl.

Second, sshd must authenticate users without PAM. Alpine’s standard openssh-server package is built without PAM, while the alternative openssh-server-pam configuration is protected when UsePAM yes is enabled.

Third, password authentication must be enabled. PasswordAuthentication yes is the relevant configuration. Systems configured for public-key-only authentication with PasswordAuthentication no are not exposed to the documented attack path.

Finally, the attacker needs an account whose password field contains *. These can include key-only users, accounts created without passwords, some identities provided through directory services, and certain cloud-image users.

Alpine also notes an additional condition: at least one local account must contain a $5$ or $6$-style password hash for the vulnerable authentication path to operate as described.

The root account deserves special attention. Alpine commonly stores root:*, but OpenSSH’s default PermitRootLogin prohibit-password prevents password authentication directly to root. As a result, a standard Alpine installation does not automatically expose direct root login through this bug.

That protection does not eliminate the broader risk. If another account with * in its password field is remotely accessible and has administrative rights through doas, sudo, container capabilities, or other privileged mechanisms, successful authentication can still provide a path to complete system compromise.

Alpine’s official tiny-cloud images are particularly relevant. Security research identified versions where the alpine account could meet the vulnerable conditions and was also able to use doas to gain elevated privileges. This illustrates why defenders should evaluate account privileges rather than assuming the vulnerability provides either harmless user access or automatic root access in every environment.

glibc-based Linux distributions such as Debian, Ubuntu, and RHEL are not affected by this specific vulnerability because the vulnerable behavior depends on musl libc’s password hashing implementation. Systems using PAM for SSH password validation are likewise outside the documented vulnerable configuration.

Containers require similar qualification. Alpine is widely used as a container base image, but ordinary containers that do not run sshd are not vulnerable through this attack path. The primary concern is containers, appliances, development environments, or legacy workloads that explicitly install and expose an SSH server.

The CVE-2026-123158 PoC landscape has developed quickly. Public reproduction labs are referenced directly by the vulnerability record, demonstrating that defenders should assume the authentication bypass can be reproduced without access to private exploit research. This materially raises remediation urgency even though confirmed malicious exploitation has not yet been reported.

The vulnerability was reported by Özgün Kültekin of Wakefield. OpenSSH publicly released version 10.6p2 with the security workaround on November 5, 2026. The reviewed primary sources do not specify the exact date on which the researcher initially discovered or privately reported the issue.

The OpenSSH fix adds validation designed to prevent error values and invalid short password hashes from being accepted during password authentication. OpenSSH notes that it considers the underlying root cause to exist outside sshd, but because the condition can be exploited through the SSH server, the project implemented a defensive workaround in OpenSSH itself.

Alpine Linux has backported the correction across multiple branches:

Alpine branch	Fixed OpenSSH package
edge	10.6_p2-r0
3.24	10.3_p1-r2
3.23	10.2_p1-r1
3.22	10.0_p1-r11
3.21	9.9_p2-r1
3.20	9.7_p1-r6
3.19	9.6_p1-r3
3.18	9.3_p2-r4
3.17	9.1_p1-r7
3.16	9.0_p1-r6

Administrators should rely on their distribution package status rather than the SSH version banner alone. Linux distributions frequently backport security patches without changing the upstream OpenSSH version displayed during the SSH handshake. A server displaying an older version string may therefore already contain the vendor fix.

For CVE-2026-123158 detection, defenders should prioritize SSH authentication telemetry. A particularly strong hunting signal is a successful password login to an account that is intended to use only public-key authentication or that has no usable password configured.

On Alpine systems, administrators can review /var/log/messages, centralized authentication logs, SIEM records, or equivalent telemetry for Accepted password events involving unexpected service, key-only, or administrative accounts.

Defenders should correlate successful authentication with source IP addresses, login times, session duration, commands executed after login, privilege elevation, changes to authorized_keys, account creation, scheduled jobs, and unexpected outbound network connections.

Network telemetry can also help identify exposed systems. Externally reachable SSH services advertising password or keyboard-interactive authentication should receive higher remediation priority, particularly when the underlying system is Alpine or another musl-based distribution.

At present, there are no campaign-specific CVE-2026-123158 IOCs such as confirmed attacker IP addresses, domains, malware hashes, or command-and-control infrastructure. The absence of static indicators makes behavioral monitoring of SSH authentication and subsequent session activity particularly important.

CVE-2026-123158 Mitigation

The primary remediation is to install OpenSSH 10.6p2 or the corrected package supplied by the Linux distribution. Alpine administrators should update the full system using the current package repositories and restart sshd afterward. Updating the package alone does not replace the already running SSH daemon process.

Organizations running Alpine-based containers should rebuild and redeploy any image that installs openssh-server. Simply updating the host operating system does not patch vulnerable OpenSSH packages embedded inside container images.

Administrators should also identify exposure before assuming that every Alpine host is vulnerable. Key checks include:

1. Determine whether the host uses musl libc.
2. Verify whether sshd is running with PAM disabled.
3. Check whether password authentication is enabled.
4. Identify login-capable accounts whose /etc/shadow password field is *.
5. Review the privileges assigned to those accounts.
6. Confirm the installed OpenSSH package against the distribution’s corrected package version.

If immediate patching is impossible, organizations should disable SSH password authentication.

Configure:

PasswordAuthentication no

and, where applicable:

KbdInteractiveAuthentication no

Administrators should confirm that public-key authentication works before applying this configuration to avoid losing legitimate administrative access.

The SSH configuration should then be validated and the daemon reloaded or restarted. Afterward, external verification should confirm that the server offers only public-key authentication.

Restricting network accessibility provides additional defense in depth. SSH should generally be reachable only from trusted administrative networks, VPN infrastructure, bastion hosts, or explicit source-IP allowlists rather than being universally exposed to the internet.

Organizations should also reconsider whether SSH is required inside containers at all. Modern orchestration environments usually provide alternatives such as docker exec or kubectl exec, eliminating an unnecessary remotely reachable authentication service.

For potentially exposed systems, review historical successful password logins occurring before remediation. Pay particular attention to accounts configured without passwords and identities normally expected to authenticate exclusively with SSH keys.

If an unexpected successful login is identified, treat the account as potentially compromised. Review shell history where available, process execution, privilege escalation, new or modified authorized_keys entries, user and group changes, cron jobs, startup scripts, package installation, and outbound network connections.

Credentials and keys accessible to the compromised account should be considered potentially exposed and rotated according to the findings of the investigation. If the account had administrative privileges, defenders should expand the investigation to the entire host and any systems reachable using credentials stored there.

Public proof-of-concept material means organizations should not wait for evidence of widespread attacks before applying the fix. The exploitation prerequisites narrow the vulnerable population, but systems that meet those conditions can be accessed remotely without knowledge of a valid password.