CVE-2026-123158: OpenSSH Authentication Bypass on Alpine Linux via 257-Byte Password

On November 5, 2026, OpenSSH released version 10.6p2, fixing an authentication flaw that specifically affects Linux systems based on musl libc, Alpine Linux foremost among them. The vulnerability, CVE-2026-123158, allows an attacker to bypass password verification by sending a password string of an unusual length — between 257 and 1024 bytes — which exploits an anomalous behavior in musl libc's crypt() function. The combination is rare but lethal: no valid credentials required, a single SSH connection, and access to accounts configured without a password.

The Mechanism: Why musl libc and OpenSSH Collided

The root of the vulnerability lies not in a typical implementation error, but in an unforeseen interaction between two standard system components. When OpenSSH sshd receives a password during authentication, it passes it to the crypt() function to compare against the hash stored in /etc/shadow. On systems with musl libc, if the password exceeds 256 bytes, crypt() returns the character '*' as an error indicator.

The problem is that many accounts configured without a password — particularly those intended for SSH key-only use — store exactly '*' in the password field of /etc/shadow. Under these conditions, sshd interprets the match between two '*' values as successful authentication, even though no correct password was supplied.

According to the source, OpenSSH addressed the vulnerability with an internal defensive fix, adding validation to prevent error values and invalid short hashes from being accepted. The source explicitly states that the OpenSSH project considers the root cause external to sshd, but implemented the workaround because the condition is exercisable through the SSH server.

The Precise Conditions: Not All Systems Are at Risk

The chain of prerequisites is tight, which has limited the attack surface, but not the impact where it materializes. For the bypass to work, four cumulative conditions are required: the system must use musl libc instead of glibc; PAM must be disabled; PasswordAuthentication must be set to yes; and the target account must have '*' in the password field of /etc/shadow.

A fifth, less intuitive requirement is added: at least one other local account must exist on the system with a password hash in SHA-256 ($5$) or SHA-512 ($6$) format. Without this presence, the vulnerable code path does not trigger. Alpine Linux satisfies these conditions in its default configuration: the openssh-server package is built without PAM and PasswordAuthentication is enabled by default.

Confirmed vulnerable versions range from 3.16 to 3.24, including the edge branch. Systems with glibc, active PAM configurations, or PasswordAuthentication no are not affected. PermitRootLogin prohibit-password blocks direct root login, but does not protect other accounts with potential elevated privileges.

"Key-Only" Accounts and the Asterisk Trap

An underestimated dimension of the vulnerability concerns the prevalence of a common but poorly understood configuration pattern. Administrators create accounts intended for SSH key-only authentication, leaving the password field set to '*' with the intention of making them inaccessible via password. The flaw demonstrates that this pattern, on musl libc, turns the absence of a password into a universal password of arbitrary length.

"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."
— Field Effect [SOURCE 3]

The case of Alpine tiny-cloud images is emblematic: the alpine account with passwordless doas privileges, once authenticated via the bypass, allows escalation to root. The conceptual simplicity of the attack — a single SSH connection with a 257-byte payload — makes it accessible even to unsophisticated operators, albeit within the specific conditions required.

The Discrepancy on In-the-Wild Exploitation

On the active threat front, the three available sources do not agree. Horizon3.ai states that "exploitation in the wild has been confirmed," without providing details on circumstances or scope. Socprime.com explicitly states the opposite: "do not report confirmed exploitation." Fieldeffect.com aligns with the latter position, reporting no indications of real-world exploits.

This divergence prevents stating the active threat status with certainty. What is documented is the availability of public proof-of-concept code, which lowers the barrier to exploitation for interested actors. The source does not specify the nature of any detection data associated with horizon3.ai.

Why It Matters

The risk concentrates on technical niches that, however, represent critical infrastructure often overlooked. Alpine Linux is widely adopted in containerized environments, security appliances, embedded platforms, and minimal cloud systems — contexts where the attack surface is deliberately reduced, but where a remote authentication flaw has disproportionate impact. The "key-only" configuration is standard in these environments, and the '*' pattern in the password field is widespread without awareness of the specific risk on musl libc.

The source does not quantify the extent of the vulnerable population exposed on the internet. The absence of census data does not equate to absence of exposure: scanners for SSH services on port 22 with identifiable banners are routine for threat actors, and the specificity of the condition chain does not protect systems that satisfy it. Alpine Linux published advisories and patched packages on November 5, 2026 for all supported branches.

Detection: What to Watch in Logs

For organizations managing Alpine or musl-based systems, the source indicates SSH authentication logs as a control point. Successful authentication events on accounts with '*' in the password field, preceded by attempts with unusually long payloads, represent the specific anomaly to correlate. The source does not detail further network signatures or indicators of compromise.

Timing is relevant: the patch has been available since November 5, 2026, but the exposure window prior to release is not quantified. The initial vulnerability report date does not emerge from the collected material.

FAQ

Which systems are definitely not vulnerable?

Systems using glibc instead of musl libc, configurations with PAM enabled, or instances with PasswordAuthentication no do not meet the flaw's conditions. The source does not report variants of the mechanism on other cryptographic libraries.

Why is the threshold exactly 257 bytes?

256 bytes represents the limit beyond which musl libc crypt() returns an error. The effective range of 257–1024 bytes is what produces the match with '*' in the password field. The source does not clarify whether lengths exceeding 1024 bytes generate different behaviors.

Are Alpine containers at risk?

Only if they run sshd and expose the service. The source does not extend the vulnerability to containers without an active SSH daemon. Tiny-cloud images with the alpine account configured represent a documented risk scenario.