OpenSSH on musl Linux can accept long passwords for key-only accounts when PAM is disabled

Alpine describes a failure when musl’s crypt() returns an error marker for an overlong password and sshd compares it with an account’s stored ‘*’ field. A reachable attacker who knows the target username can authenticate with a 257–1024-byte password if password authentication is enabled, PAM is not used and another local account supplies a $5$ or $6$ password hash. The discoverer’s reproduction requires a failed password attempt earlier in the same connection. This is not a universal OpenSSH or Alpine compromise. Accounts locked with ‘!’ are excluded; root still needs PermitRootLogin yes for direct password entry, while another affected account may obtain root through its own privileges.

Alpine lists affected releases 3.16–3.24 and edge. Its tiny-cloud images are safe initially but may become exposed after an administrator adds a qualifying password hash; the preconfigured alpine account has passwordless doas. Cloud-init images configured with password authentication disabled and containers with no sshd are outside that path. Upstream 10.6p2 is a workaround, while stable Alpine branches retain older upstream version numbers with patched package revisions. No version checker is supplied for these distribution-specific versions. The initial notices establish the flaw and remediation. They predate the sensor report below.

Identifier follow-up: The CNA has now been checked and links this flaw to CVE-2026-123158. Its brief description gives 256–1024 characters; Alpine’s detailed explanation requires over 256 bytes and explicitly gives 257–1024 bytes, retained above. The identifier does not change the account prerequisites, patched package revisions or restart requirement. Red Hat’s not-affected assessment applies to its product builds, not every Linux installation.

November 6 exploitation evidence. Previdian’s initial public sensor report lists eight attempts from one source IP. Its CEO separately told The Hacker News that one reached root on a honeypot running Alpine and OpenSSH, and reported non-interactive reconnaissance. Observed attempts and successful access to the monitoring environment justify L4. On November 7 the public dashboard shows 17 attempts across four sensors from 11 source IPs geolocated to eight countries. The counts describe sensor observations. The findings establish neither production victims nor changes to vendor prerequisites or fix versions.

StepSecurity independently reproduced that sequence in an Alpine 3.24 VM and container using 10.3_p1-r1. The bypass failed after installing 10.3_p1-r2 and restarting sshd. Its client and askpass setup could deliver at most 1023 bytes. Alpine still documents a server range of 257–1024 bytes. GitHub tracks the same issue as GHSA-4fcc-vm97-gx3x.