OpenSSH 10.6p2 Vulnerability: Turn Off Password SSH on Musl Hosts

OpenSSH 10.6p2, released on 5 November 2026, is a critical workaround release: earlier versions of sshd are vulnerable on Linux systems running musl libc without PAM, Alpine Linux included. Until the OpenSSH 10.6p2 vulnerability fix is installed, maintainer Damien Miller's instruction is blunt: turn off password authentication on those hosts, or turn off SSH.

What did OpenSSH release on 5 November 2026?

OpenSSH 10.6p2 is a security release, not a feature release. Miller announced it on Hachyderm, a tech-focused Mastodon instance, and his post opened with an order: operators of musl-based Linux without PAM should “stop reading and set PasswordAuthentication=no or disable SSH for these systems IMMEDIATELY.”

Miller wrote that the project “learned of the problem yesterday,” which puts the report on or around 4 November. He credited Özgün Kültekin of Wakefield with the finding. Alpine Linux developers shipped an updated package almost immediately, but the thread gives no version number, so check your own repositories.

There is no CVE ID, CVSS score or technical write-up yet. An empty NVD search means the advisory pipeline is lagging, not that your hosts are safe.

Which Linux hosts are exposed to the OpenSSH 10.6p2 vulnerability?

Exposed hosts are Linux machines where sshd runs on musl libc and checks passwords without PAM. The maintainer named Alpine Linux as the example. In a reply, Miller confirmed a case the release notes leave unclear: a build compiled with –with-pam is still affected if the runtime configuration sets UsePAM no.

The notes say the workaround applies “when built and run with PAM support disabled.” Leah Neukirchen asked whether that “and” should be “or”; Miller had already answered “yes it does apply to this configuration,” though no correction to the notes appeared in the thread. The working rule: if PAM is not handling passwords on a musl host, treat that host as exposed.

Start with internet-facing musl hosts that offer a password prompt on port 22. Finding those prompts across your address space is routine work in external network penetration testing.

What should operators do before they upgrade?

Switch password authentication off on every affected host now, then upgrade.

1. Scope by libc and auth path, not hostname. Running ldd on the sshd binary shows musl or glibc. sshd -T prints the effective usepam and passwordauthentication values.
2. Set PasswordAuthentication no and reload. Confirm with sshd -T, not the config file, and look for Match blocks that re-enable passwords for specific users or groups.
3. If keys are not deployed yet, stop sshd or restrict port 22 to a management network until they are.
4. Install OpenSSH 10.6p2 or the Alpine update, and rebuild any image that bakes in sshd. Patching a running container does not fix its image.
5. Record the decision: trigger, affected assets, mitigation and timestamps. CySEC, NIS2 and DORA reviewers will ask for that trail.

PasswordAuthentication no is a CIS Benchmark control, so most audited firms already enforce it on their core servers.

Practitioner’s note: on our engagements, hosts that still accept SSH passwords rarely sit in the managed fleet. They are supplier jump containers, debug sidecars left in staging namespaces, or vendor appliances running Alpine underneath, and they seldom appear in the asset register. Check them first.

Are containers and embedded devices affected? Is Dropbear?

Alpine containers that run sshd with password login are affected. Alpine is one of the most widely used bases for minimal container images, but most application containers run no SSH server, so check which images actually include sshd before you escalate. A container security assessment answers that across registries and running workloads.

Dropbear, the small SSH server common on routers and embedded firmware, is a separate codebase and is not affected. Natanael Copa of Alpine said he had verified the Dropbear sources, and Rich Felker of musl agreed. The catch is vendor hardware: a box that runs OpenSSH on musl is exposed, so ask your suppliers which SSH server they ship.

Why did OpenSSH skip a long embargo?

OpenSSH no longer trusts that a reported bug stays secret. Miller wrote that the project has seen “multiple cases of rapid bug rediscovery by AI agents, sometimes within hours,” and now considers long embargo periods “a dangerous practice that primarily benefits attackers.” Coordinated disclosure has commonly allowed weeks or months between report and fix. One day is a deliberate break.

Expect more releases like this: sparse detail, no CVE on day one, and the first word on Mastodon rather than a mailing list. Add the maintainer accounts for your critical open-source components to threat-intel monitoring.

NIS2 expects essential and important entities to handle vulnerabilities and patch on time, and DORA, applicable since 17 January 2025, sets ICT risk and patch-management duties for financial entities. Leaving a critical sshd flaw open while waiting for a CVE number is hard to defend in either review. Our NIS2 and DORA readiness work builds that same-day decision into a written patch procedure.

What is still unknown, and whose bug is it?

The mechanism, any affected musl versions, the Alpine package number, a CVE and a severity score are all still private. The source thread contains no reports of exploitation in the wild.

Each project places the root cause elsewhere. OpenSSH considers it outside its own code and shipped the mitigation because it could deliver one fastest. Felker, posting as Cassandrich, wrote that “it is not a musl vulnerability” and is holding back details until users have mitigated. Either way, patch sshd now and take musl or Alpine updates as they appear.

One community explainer wrote that the flaw probably gives “everyone on the internet admin access” to affected servers. That was a reader’s interpretation, not an OpenSSH statement, and nobody confirmed another reader’s guess about a known musl regex issue.

FAQ

Does the flaw affect every Alpine container?

No. It matters only where OpenSSH's sshd runs and accepts passwords without PAM; containers without sshd or with key-only login are not exposed this way.

If sshd was compiled with –with-pam and UsePAM is no, am I exposed?

Yes, on musl. Damien Miller confirmed it, so judge by runtime settings, not build flags.

Is Dropbear on embedded routers affected?

No. Alpine's Natanael Copa verified the Dropbear sources, and musl's Rich Felker agreed.

Is there a CVE or CVSS score for this OpenSSH issue?

Not at release time. The release notes call the workaround critical, but no CVE ID, CVSS score or technical write-up has been published.

If you are not sure which of your servers, containers or vendor appliances still accept SSH passwords, a network and infrastructure penetration test maps them and produces the evidence trail your CySEC, NIS2 or DORA reviewer will ask for.