OpenSSH 10.6p2: critical password bypass on musl Linux without PAM (Alpine), what to do

OpenSSH 10.6p2, released on 5 November 2026, works around a critical password authentication bypass that affects Linux systems built on the musl C library and run without PAM, which includes Alpine Linux. Systems on glibc, on PAM, on OpenBSD or on non-Linux platforms are not affected. The OpenSSH developers tell administrators of affected machines to turn off password logins or SSH itself immediately.

Key points

• OpenSSH 10.6p2 (Portable) was released on 5 November 2026 with a workaround for a critical password authentication bypass in sshd, according to the OpenSSH release notes.
• Affected: Linux systems that use musl libc and do not use PAM for password authentication, such as Alpine Linux. Not affected: non-Linux systems, Linux with glibc, and Linux using PAM, says the OpenBSD Journal's account of the announcement.
• The OpenSSH team says the root cause lies outside sshd, but that it can be exploited through sshd and avoided there. The release notes list no CVE number.
• The immediate mitigation is PasswordAuthentication no in the sshd configuration, or disabling SSH on affected systems, until the update is installed.
• The reporter, Ozgun Kultekin of Wakefield, published his own write-up at sshhole.com.

What to do

Check whether you are affected. All three of these must be true: sshd runs on a musl-based Linux (Alpine, OpenWrt, Buildroot, Yocto and many container base images are examples), sshd does not authenticate passwords through PAM (the researcher says Alpine's openssh-server does not use PAM by default, and that UsePAM no has the same effect), and password logins are enabled, which is the OpenSSH default. Debian, Ubuntu, Fedora and other glibc distributions that go through PAM are not affected, according to the researcher and to the Linux Magazine report.

Close the hole now. Add this line to the sshd configuration (for example a file in /etc/ssh/sshd_config.d/) and restart sshd:

PasswordAuthentication no

On Alpine, the researcher's page gives the restart command as rc-service sshd restart. This is the workaround both the OpenSSH developers and the Alpine team recommend, per the reports linked below. Key-based logins are not touched by this setting.

Then update. Upgrade to OpenSSH 10.6p2 or to your distribution's patched package. On Alpine the researcher's page suggests apk upgrade openssh. Alpine has said it will backport the fix to releases as far back as 3.16, according to Linux Magazine. We could not confirm the exact fixed Alpine package version, so check your package manager's output or Alpine's security tracker. Some other distributions and download mirrors were reported to be still serving 10.6p1 on the day of release, so verify what you actually get.

Check whether it was used. The researcher's page tells readers to look for a successful password login by an account that has no password set. We could not independently verify his detection method, and sshd logs on your system are the place to start.

What happened

On 5 November 2026 Damien Miller, a long-time OpenSSH developer, announced Portable OpenSSH 10.6p2. The release notes describe a critical security fix, worded as avoiding a password authentication bypass that is exploitable through sshd(8). They say it concerns some Linux systems built and run with PAM support disabled, and name musl libc as the case. The notes credit Ozgun Kultekin of Wakefield with the report.

The announcement says the team learned of the problem only the day before the release. It explains the speed: the developers cite recent cases in which AI agents rediscovered bugs within hours, which they consider makes long embargoes risky, and they say they will make more frequent releases for now. This is the developers' own reasoning, and we have no independent measure of how often that rediscovery happens.

The release carries a few smaller changes as well: the ssh-mldsa44-ed25519 post-quantum hybrid signature is enabled as an allowed CA signature algorithm, a CPU spin when ChannelTimeout is used is fixed, and several portability problems are fixed.

Background

OpenSSH 10.6 had arrived on 6 October 2026 with a different set of security changes. According to its release notes, sftp became stricter about paths returned by a server (otherwise a recursive copy could write outside its target directory), sshd stores GSSAPI credentials only after successful authentication, LZ77 dictionary coding was disabled to mitigate a side channel on shared compression contexts (so the Compression option is less effective), and command-line usernames containing $ or \ are rejected to reduce shell injection risk. None of those concern the bug fixed in 10.6p2.

The researcher's write-up traces how the musl case came about. It describes it as a chain of small decisions over many years rather than one mistake. In his account, musl's crypt() stopped returning NULL on failure in 2012 and returns the single character * instead, and musl's SHA-512 crypt refuses passwords longer than 256 bytes, which is also a failure. In Unix password files an account locked with * can never match a real hash, so a password check against it normally fails. The write-up says sshd, since a 2016 change to hide which usernames exist, hashes the typed password against some other account's salt for users without a usable hash, and that on musl without PAM this path ends up accepting an over-long password for an account whose field is *. He adds that Alpine moved root to * in release 3.16 in 2022, so that keys keep working. These are his claims, checked by us only against the pages he links, not by an independent audit, and neither OpenSSH nor Alpine has published a technical description that we could open. Treat the mechanism as the researcher's account, not as a confirmed root cause.

How it works

The researcher's page states the practical consequence this way: on musl without PAM, accounts that should never accept a password (root, a key-only deploy user, LDAP users, the default user on Alpine's AWS and Azure images) accept any password between 257 and 1,024 characters long, and he reports the default Alpine cloud-image user has passwordless doas, which makes it effectively root. He says a freshly created machine with no passwords set is not affected.

That page also says the researcher found the bug by building sshd in many ways (glibc, musl, with and without PAM, with and without shadow passwords), running about 17,600 odd logins against each build, and using many AI agents to do it. Every build agreed except musl without PAM. We cannot verify those figures. They are his description of his own method.

The reason the combination went unnoticed, in his telling, is that OpenSSH is tested mainly on OpenBSD and glibc, that musl does not test sshd, and that most distributions go through PAM, which never calls crypt() for a * entry. Whether Dropbear is affected was asked in the developer's Mastodon thread, and we found no answer.

What it means

For anyone running Alpine in containers or on small servers, this is the practical story: Alpine is a very common base image, and many images that ship an SSH server are used for appliances, CI machines and lab environments. A container that exposes SSH with password login is the risky case. If you only expose SSH with keys, or not at all, the bug is not reachable in the way described.

For maintainers of minimal distributions (OpenWrt, Buildroot, Yocto) the same combination, musl without PAM, applies in principle. Check your own images.

For the wider ecosystem the episode is a reminder that "key-only" is a stronger posture than "password login with locked accounts". It also shows how the OpenSSH team now weighs disclosure: a fix within a day of learning of the bug, justified by faster AI-assisted rediscovery.

What we don't know yet

• There is no CVE identifier in the release notes. We will not guess one.
• Neither OpenSSH nor Alpine has, in the pages we could open, published a full technical description of the bug, so the 256-character mechanism comes from the researcher alone.
• We could not confirm the Alpine package version that contains the fix, or the exact list of Alpine releases that already have it beyond Alpine's statement about going back to 3.16.
• Whether Dropbear or other SSH servers on musl are affected has been asked but not answered in what we found.
• Whether anyone exploited the bug before the release is unknown. The researcher says that as far as anyone knows, nobody noticed.
• One reply in the developer's Mastodon thread, as summarized by a search tool, says the problem also applies when PAM is compiled in but UsePAM no is set. We could not open the thread, so treat it as unconfirmed.

What to watch next

Watch for a CVE assignment, for Alpine's package notes and security tracker entries, and for updates from OpenWrt, Buildroot and Yocto. OpenSSH said it will release more frequently for now, so another point release is plausible. If you maintain container images, rebuild and redeploy them once your base image has the patched openssh package.

For background on how weaknesses in widely deployed tools get weaponised quickly, see our piece on OpenAI's AI pipeline that built 948 Linux root exploits in one run.

Sources

• OpenSSH release notes, 10.6p2 and 10.6 (primary)
• OpenSSH 10.6p2 released, OpenBSD Journal
• sshhole.com, the reporter's write-up
• Ernstig beveiligingslek in OpenSSH raakt Alpine Linux-systemen, Linux Magazine (Dutch)
• Hacker News discussion of the release