Alpine OpenSSH password bypass requires patching and an sshd restart

November 5 fixes create an immediate patching priority

OpenSSH released version 10.6p2 on November 5 to address a password-authentication bypass on Linux systems using musl without PAM authentication. Now tracked as CVE-2026-123158, the flaw can let an attacker enter an account intended not to accept passwords. For November 6, the actionable development is the availability of fixes and exposure guidance, not a second discovery or proof that all OpenSSH installations are compromised. [1][9][10]

Alpine identifies releases 3.16 through 3.24 and edge as potentially affected, subject to specific configuration requirements. It has published corrected packages and distribution images. Updating the package alone is insufficient because the existing server process continues running: administrators must also restart sshd. That operational requirement matters alongside the version check, particularly where updates are installed without restarting services. [3][9]

Exposure depends on accounts, authentication settings and the SSH server

Check Point describes four conditions that must coincide: OpenSSH runs on musl-based Linux without PAM; SSH password authentication is enabled; the target account’s password field contains an asterisk; and another active local account has a real SHA-256 or SHA-512 password hash, identified by the $5$ or $6$ prefix. Its testing found that merely retaining the second account’s hash was insufficient. The account had to be active, an important qualification for exposure assessments. [8]

This is not a general Linux or container vulnerability. Alpine containers without a running sshd, PAM-enabled configurations and systems with SSH password authentication disabled are outside this attack path. Red Hat says its products are unaffected because their OpenSSH builds use glibc and PAM. Amazon lists Amazon Linux 2, 2023 and 2027 Preview as unaffected, which says nothing about an Alpine image deployed on AWS. Musl’s maintainer also explicitly excludes Dropbear. [9][10][11][12]

Alpine’s tiny-cloud images illustrate how exposure can change after deployment. The project says affected images are safe on first boot but can become exploitable when a qualifying password hash is added. Their default alpine account has passwordless doas, making access to that account a route to root. OpenSSH’s default PermitRootLogin prohibit-password blocks direct root password login, but does not prevent escalation through another account with sufficient privileges. [8][9]

The failure confuses an error marker with authentication success

The researcher’s explanation describes an authentication-logic failure, not password cracking. For certain oversized password inputs, musl’s crypt() function returns an asterisk as an error indicator. An account configured not to accept passwords can also contain an asterisk in its stored password field. The vulnerable comparison can mistake those matching markers for a successful password check. A timing-defense mechanism that borrows another account’s salt forms part of the failure path. [2]

Check Point reports testing oversized inputs from 257 to 1,024 bytes. The upstream correction adds a minimum stored-hash-length check before accepting a match, providing code-level evidence of how OpenSSH prevents the bypass. The sources do not justify describing the ordinary case as a single password submission: Alpine discusses one connection, while the researcher says the asterisk case requires an initial failed attempt. [2][7][8][9]

Separate testing supports the flaw, while responsibility remains disputed

OpenSSH’s release notice and repository change are primary evidence of the upstream response; Alpine’s advisory establishes its distribution scope and remediation instructions. Check Point supplies a separate testing layer, including the active-account qualification. Ars Technica provides separate reporting, but it should not be counted as an independent laboratory reproduction. Reporting that repeats the disclosure does not add another technical confirmation simply because it appears on another publisher’s website. [1][7][8][9][13]

The maintainers disagree about responsibility. OpenSSH considers the root cause outside sshd, while musl maintainer Rich Felker describes erroneous use by the caller rather than a musl bug. That disagreement does not change the immediate response: OpenSSH has supplied a workaround, and Alpine has distributed corrected packages and mitigation guidance. [1][9][12]

Severity assessments also differ. Red Hat displays a CVSS 3.1 score of 8.1 with high attack complexity, while AWS displays 9.8 with low complexity. Neither score should replace checking the actual prerequisites. Both vendors identify the CVE while declaring their own listed products unaffected, underscoring the difference between a vulnerability rating and a particular system’s exposure. [10]

Use Alpine’s fixed packages, then restart the daemon

Alpine’s fixed openssh packages include 10.6_p2-r0 for edge, 10.3_p1-r2 for 3.24, 10.2_p1-r1 for 3.23, 10.0_p1-r11 for 3.22 and 9.9_p2-r1 for 3.21. Its advisory also lists backports through 3.16. Administrators should follow their branch’s package guidance and restart sshd after installation, rather than assuming that only an upstream 10.6p2 version string demonstrates remediation. [9]

The November 5 distribution releases 3.21.10, 3.22.8, 3.23.8 and 3.24.4 include the correction. Taken together, the distribution release notes and package advisory show why checking only a server’s apparent upstream version can mislead: Alpine has shipped fixes on older upstream branches as well as edge. [3][9]

If patching must wait, Alpine and the musl maintainer recommend setting PasswordAuthentication no and restarting sshd. Verify working public-key access before making that change to avoid locking out administrators. This mitigation removes a required condition for the bypass; it does not determine whether unauthorized access occurred before password authentication was disabled. [3][9][12]

Check prior access and watch for confirmed exploitation

Alpine recommends reviewing authentication logs for Accepted password for entries involving accounts that should not accept passwords. Investigators should also examine privilege escalation, newly created users and files, and changes to authorized keys. Its guidance is to treat a machine as compromised if unauthorized login cannot be ruled out. A successful update therefore closes the vulnerable path but does not settle the machine’s earlier security history. [9]

The reviewed disclosures establish the flaw and corrective action, but not a reliable vulnerable-system count or a confirmed malicious exploitation campaign. Our assessment is that matching cloud configurations with privileged accounts deserve particular attention because Alpine documents a route from account access to root. Next, watch for corroborated exploitation reports and further distribution guidance. Counts of open SSH ports or image downloads cannot establish how many systems meet the required conditions. [1][8][9]