OpenSSH 10.6p2 fixes a password login bypass in Linux builds using musl without PAM
OpenSSH 10.6p2 fixes a password login bypass in Linux builds that use musl with PAM disabled, and Previdian reported exploitation attempts within hours of disclosure.
The OpenSSH project released version 10.6p2 on November 5, 2026, to fix a password authentication bypass in some Linux builds of its SSH server. The flaw lets an attacker log in to accounts that have no usable password, without stolen credentials or SSH keys.
The Hacker News reported on November 6 that threat actors were attempting to exploit the flaw, according to Previdian. Alpine Linux published its own security advisory on November 5.
Which systems are exposed
The Hacker News says the bypass affects Linux systems running OpenSSH built on the musl C library with PAM disabled. Alpine's advisory describes a similar setup: sshd built without PAM, or openssh-server-pam running with UsePAM set to no, and PasswordAuthentication set to yes.
The attacker submits a password of 257 to 1,024 bytes. Alpine says the attack works when another local account has a $5$ or $6$ password hash. It needs at least one account whose stored hash is an asterisk, such as a key-only user or root with an asterisk hash. The Hacker News says accounts with valid password hashes are not bypassed.
According to The Hacker News, Dropbear, glibc-based distributions, non-Linux systems and systems that check passwords through PAM are not affected. Alpine says it checked releases 3.16 through 3.24, plus edge, and lists a fixed package for each of those branches.
Exploitation reported within hours
The Hacker News reports that Previdian saw the first exploitation attempt less than nine hours after the CVE was published. Previdian is a security firm named in the article.
Previdian says it confirmed root access on a honeypot running Alpine Linux and OpenSSH. It recorded eight attempts in total from one IP address, which The Hacker News says geolocates to Japan. Previdian says the attacker ran id, uname and hostname commands through non-interactive SSH sessions.
The root-access result comes from a single honeypot, according to Previdian. As of November 6, 2026, the reporting does not say how many real-world systems were compromised.
Fixed versions and administrator steps
OpenSSH's release notes list 10.6p2 as the fixed version. Alpine's edge packages carry 10.6_p2-r0. For stable branches, Alpine lists 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, with older fixes for 3.16 through 3.20 in its advisory.
Alpine advises running an upgrade and then restarting sshd, because upgrading the package does not restart a running server. If an upgrade cannot be installed yet, Alpine says to set password authentication to off and restart sshd, after confirming key-based login works and keeping a session open.
Alpine also advises checking system logs for password logins to accounts that should not accept them, reviewing use of doas, new users and authorized keys, and treating a machine as compromised if a login cannot be ruled out. The Hacker News gives the same restart guidance.
“The bypass works only where password authentication is enabled, sshd is built or run without PAM on musl libc, and an account has an asterisk password hash.”
Open points in the reporting
Neither OpenSSH's release notes nor Alpine's advisory gives a CVE number for this flaw; Alpine says none had been assigned when it was written. The Hacker News gives CVE-2026-123158 with a CVSS score of 8.1 but does not name the source of the score.
The sources describe the root cause differently. OpenSSH's notes say the root cause lies outside sshd but can be avoided there. Alpine ties the bypass to musl's crypt() returning an asterisk for overlong passwords. The Hacker News traces it to a 2016 patch for CVE-2016-6210, a username enumeration fix.
OpenSSH's notes credit the discovery to Özgün Kültekin of Wakefield, and The Hacker News spells the name Ozgun Kultekin. For businesses that run Linux servers, the reporting ties exposure to conditions including whether the server build uses PAM and whether password logins are enabled.
