OpenSSH 10.6p2 fixes a no-password login on Alpine and other musl systems — and speeds up releases, citing AI bug-hunting

OpenSSH released version 10.6p2 on November 5, 2026 to close a password authentication bypass in sshd that, in the project's words, "affects some Linux systems when built and run with PAM support disabled". The same day, Alpine Linux published an advisory with fixed openssh-server packages for every release from 3.16 to 3.24 and edge — including end-of-life branches. No CVE had been assigned when either was published. (OpenSSH, Alpine)

The release also carries a policy change with an AI angle: OpenSSH says it will, "for now, be making more frequent releases" instead of batching fixes, because it has seen cases where "a security bug identified by AI tools is subsequently independently discovered by a different researcher" — a sign that attackers who never report may be finding the same bugs.

What the bug is

According to Alpine's advisory, when sshd runs without PAM it checks passwords with the C library's crypt() function. musl's crypt() returns the string * as its error value for keys longer than 256 bytes. Accounts that have no usable password also store * in the password field. So an attacker who sends a password between 257 and 1024 bytes long gets an error string that happens to match the stored "no password" marker — and sshd accepts the login.

Alpine lists two conditions on the target machine: an account whose password field is *, and at least one other local account with a $5$ or $6$ (SHA-256/SHA-512 crypt) hash. OpenSSH says it considers "the root cause of this bug to be outside sshd" — in the C library's behaviour — but that it "can be avoided there", so 10.6p2 adds a workaround in sshd itself.

The bug was reported by Özgün Kültekin of Wakefield, credited by both OpenSSH and Alpine. Neither source says how the bug was found; the AI remark in the release notes is about the project's release policy in general, not a claim about this report.

Who is affected

Per Alpine, a system is exposed if all of these hold:

• it runs openssh-server without PAM, or openssh-server-pam with UsePAM no;
• PasswordAuthentication yes is set;
• some account has * as its password — Alpine names root in base images, key-only users, directory-service users, and the alpine user in tiny-cloud images;
• at least one account has a $5$ or $6$ hash.

Not affected: PasswordAuthentication no, openssh-server-pam with UsePAM yes, accounts locked with !, systems with no $-style hashes, and containers that do not run sshd.

Cloud images deserve a look first. Alpine says its official tiny-cloud images from 3.18.11 through 3.24.3 ship an alpine user with a * password and passwordless doas — so a successful login there is effectively root. These images become exploitable as soon as a $6$ hash exists on the machine, for example after someone sets a password for another user. Images built from the fixed releases are safe.

OpenSSH's notes frame the issue as "some Linux systems" and describe the workaround as aimed at musl-based builds with PAM disabled; Alpine is the most widely deployed such distribution, but other musl-based systems that build OpenSSH without PAM should check with their maintainers.

Fixed versions (Alpine)

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

What to do

• Update and restart. Alpine's advice is apk upgrade -U -a followed by rc-service sshd restart; the upgrade alone does not replace the running daemon.
• If you cannot update yet, set PasswordAuthentication no and restart sshd — after confirming key-based login works, and with a second session kept open.
• Check for compromise. Alpine suggests looking in /var/log/messages for "Accepted password for" entries on accounts that have no password, and reviewing doas use, new users, new files and authorized_keys. If a login cannot be ruled out, treat the machine as compromised.
• Audit images, not just hosts. Base images and golden images built on affected tiny-cloud releases carry the vulnerable alpine user; rebuild them from fixed releases.

Why the release-cadence change matters

Our assessment: OpenSSH has long been one of the most conservative projects in open source, shipping fixes on a planned schedule. Saying publicly that AI-assisted discovery has shortened the gap between one finder and the next — and changing release practice because of it — is a notable signal from a project of its standing. It matches what we have seen across recent reports of AI-found vulnerabilities: when bugs are found faster and by more people at once, holding a fix for the next scheduled release becomes a risk in itself. For defenders the practical consequence is the same: expect more frequent OpenSSH point releases, and make sure the restart step is part of your patch routine, not an afterthought.

Other changes in 10.6p2, per the release notes: scp -R (remote-to-remote copy) now prints a deprecation warning; sshd support for platforms lacking file-descriptor passing (such as SCO OpenServer 5 and QNX 6) is slated for removal; the post-quantum ssh-mldsa44-ed25519 scheme can now be used as a CA signature algorithm; and a CPU spin with ChannelTimeout is fixed.

Sources

• OpenSSH, release notes for 10.6p2 (2026-11-05): https://www.openssh.org/txt/release-10.6p2
• Alpine Linux, "openssh-server password authentication bypass" (2026-11-05): https://alpinelinux.org/posts/2026-11-05-openssh-password-authentication-bypass/