OpenSSH 10.6p2, released on 5 November 2026, is an emergency workaround for Linux servers that run musl libc without PAM, and Alpine Linux is the named example. If any server that hosts or supports your site allows Alpine OpenSSH password login, maintainer Damien Miller's advice is to switch it off today, before you patch.
Key takeaways
- OpenSSH 10.6p2 (5 November 2026) is a critical workaround for Linux on musl libc where password login does not go through PAM; Alpine is the named example.
- glibc Linux, non-Linux systems and hosts that use PAM for password authentication are not affected.
- Set PasswordAuthentication no or disable SSH now, then install the fixed package and confirm with ssh -V or apk info -v openssh.
- The release announcement names no CVE, severity score or root cause. Dropbear is not affected.
What did OpenSSH ship on 5 November 2026?
Do this now: if an Alpine or other musl-based server runs OpenSSH with password login and without PAM, set PasswordAuthentication no or stop sshd, then install 10.6p2 or your distribution’s fixed package.
Damien Miller announced 10.6p2 on the Hachyderm Mastodon server as a release “with a workaround for a critical vulnerability” and explained: “We consider the root cause of this bug to be outside OpenSSH itself, but we’re in a good position to deliver a mitigation quickly.” The team learned of the problem the day before the release, from a report by Özgün Kültekin of Wakefield. Alpine Linux developers shipped an updated release in the same window, and Miller thanked them publicly.
The release announcement names no CVE or severity score and offers no root cause or exploit detail. Miller calls the bug critical but does not describe its impact. One commenter summarized the worst case as admin access for anyone on the internet on affected machines. Treat that as a reading of the announcement, not an OpenSSH statement.
Is the server that hosts your site in the affected set?
Three conditions must all hold: the server runs Linux, it uses the musl C library, and SSH password logins do not go through PAM.
- Affected: Linux with musl libc (Alpine is the named example), where password authentication is handled without PAM.
- Not affected, per Miller: non-Linux systems such as BSD and macOS; Linux on glibc (Ubuntu, Debian, AlmaLinux, Rocky, CloudLinux and similar); Linux that uses PAM for password authentication.
The PAM condition has a catch. OpenSSH has a –with-pam build option and a UsePAM setting in sshd_config. When Leah Neukirchen asked about a binary built with PAM support and running with UsePAM no, Miller replied: “yes it does apply to this configuration.” Package metadata that mentions PAM does not clear you; the running configuration decides. OpenSSH has published no list of affected earlier releases or musl versions, so treat anything older than 10.6p2 in this configuration as exposed.
How do you tell Alpine and musl from a typical glibc host?
Check what answers SSH on every IP address you own, not only the servers you remember. The Alpine machines that slip through are the ones nobody wrote down: an upload container, a staging image on port 22 or 2222, a retired backup target. Shared hosting and cPanel servers typically run glibc; their recent risk is a different flaw, covered in our write-up on cPanel shared-hosting risk.
With shell access, three commands answer the question:
- cat /etc/os-release shows the distribution.
- ldd $(which sshd) shows the C library: ld-musl means musl, libc.so.6 means glibc.
- sshd -T | grep -iE ‘usepam|passwordauthentication’, run as root, prints the effective settings after includes and defaults.
musl, “usepam no” and “passwordauthentication yes” together put a server at the top of your fix list. With panel access only, ask your host which distribution and C library the SSH server runs on, whether password login is enabled, and whether OpenSSH 10.6p2 or the updated Alpine package is installed.
How do you turn off Alpine OpenSSH password login safely?
Disable password authentication first, then upgrade. Miller told operators of affected systems to set PasswordAuthentication=no or disable SSH “IMMEDIATELY,” and that protects you whether or not a package is ready.
- Secure a way back in. Confirm that a key-based login or your VPS provider’s web console works.
- Set PasswordAuthentication no in sshd_config. Check files under sshd_config.d and any Match blocks, which can re-enable passwords for specific users. Reload sshd and confirm with sshd -T.
- No keys yet? Stop sshd, or allow port 22 only from known IP addresses at the firewall, until the update is in.
- Upgrade and verify. Record ssh -V and apk info -v openssh, upgrade the openssh packages through apk from the official repositories, then run both again. Miller’s post gives no Alpine package version, so match the fixed release Alpine announces and check whether it reached your branch or only edge.
- Rebuild containers from a refreshed base image. Changes made inside a running container vanish when it is recreated.
- Move password workflows to keys. SFTP clients, deploy scripts and backup jobs that log in with passwords will now fail.
Keep password login off after the upgrade. 10.6p2 works around a problem OpenSSH places outside its own code, so a separate fix may still follow.
Are containers, panels and Dropbear the same problem?
No. Natanael Copa (@ncopa) said he verified the Dropbear sources and wrote that “dropbear is not affected,” which covers many routers and embedded devices. Most web application containers run no SSH server at all. On the musl side, @dalias said “it is not a musl vulnerability” but, like Miller, declined to give details until affected systems are mitigated. Community theories about the mechanism are unconfirmed.
Disabling password login blocks future break-ins; it does not undo one that already happened. On an Alpine host that had password SSH open, search the logs (often /var/log/messages) for “Accepted password” lines from unfamiliar addresses, and check authorized_keys files and /etc/passwd for entries nobody added. An exploit may not log like a normal login, so also scan the site files with antivirus website protection.
Why did OpenSSH skip a long embargo?
Miller wrote that OpenSSH has “recently observed multiple cases of rapid bug rediscovery by AI agents, sometimes within hours, and so now consider long embargo periods to be a dangerous practice that primarily benefits attackers.” If the maintainers expect rediscovery within hours, “we’ll patch next week” leaves a password-enabled musl host exposed. Ask your provider for a timeline measured in hours, not days.
Still unknown: a CVE identifier, a severity score, the affected musl versions and the exact mechanism.
FAQ
Does OpenSSH 10.6p2 affect my Ubuntu WordPress VPS?
No. Ubuntu uses glibc, and Damien Miller stated that glibc-based Linux is not affected.
If sshd was built with PAM but UsePAM is no, am I affected?
Yes, if the system runs on musl; Miller confirmed this configuration is in scope. Check the live value with sshd -T.
Is Dropbear on my router or device part of this OpenSSH issue?
No. Natanael Copa (@ncopa) said he verified the Dropbear sources and that Dropbear is not affected.
Should I wait for a CVE number before I act?
No. The release announcement names no CVE. On affected hosts, disable password login now.
Not sure what answers SSH across your servers, containers and staging boxes? Our website protection packages cover the site files, and you can ask us to include a review of the server side too.
