What did OpenSSH release on 5 November 2026?
OpenSSH released version 10.6p2 on 5 November 2026. The release notes call it "a critical security workaround." It targets Linux systems that use the musl C library and run sshd with PAM disabled. Alpine Linux is the most prominent distribution in that group.
Alpine published its own advisory the same day. It told administrators to update the openssh package and restart sshd, or to switch off password logins immediately. The advisory is blunt about one detail. "Upgrading the package alone does not replace the running daemon."
The flaw now carries the identifier CVE-2026-123158. NIST’s National Vulnerability Database published the record on 5 November at 16:17 UTC. It gives the bug a CVSS 3.1 base score of 8.1, in the high range. The vector marks attack complexity as high, because several conditions must line up.
Version 10.6 had arrived on 6 October. The point release followed a month later, after Özgün Kültekin of Wakefield reported the issue. Alpine’s advisory credits Kültekin, Timo Teräs for analysis and Natanael Copa for building the updated packages.
On the affected combination, a remote attacker can log in without knowing a password. The target account must have no usable password hash. The machine must also hold another account with a modern password hash. Those conditions are specific, but common enough on real Alpine hosts.
Which Alpine and musl systems are affected?
Alpine says every release it checked is affected: 3.16 through 3.24 and the rolling edge branch. The project also shipped fixed packages for older, unsupported branches back to 3.16. Docker containers that do not run sshd inside them are not exposed.
You are affected if all four conditions are true:
- •You run openssh-server, which Alpine builds without PAM, or openssh-server-pam with UsePAM no.
- •PasswordAuthentication is yes, which is the OpenSSH default unless you changed it.
- •The machine has an account whose password field is "*", meaning no usable hash is stored.
- •At least one local account has a $5$ or $6$ password hash.
What makes musl and PAM different on Alpine?
Alpine uses musl as its C library and BusyBox for core utilities. The distribution also builds the ordinary openssh-server package without PAM, the pluggable authentication layer that most Linux distributions use to check passwords. This is a build choice, not a runtime setting.
The trade-off appears in the password check. Without PAM, sshd calls crypt() directly and compares the returned string with the stored field. Most distributions never take that path for password logins. That is why the same OpenSSH code behaves safely on Ubuntu, Debian and Fedora.
Accounts with an asterisk in the password field are not exotic. Alpine ships root as root:* in its base image from about version 3.16 onward. Key-only users created without a password also get that field. So do directory-service users coming through musl-nscd, because they have no local shadow entry.
Root is usually shielded by PermitRootLogin prohibit-password. That shield fails if another reachable account can escalate, for example through doas. The advisory notes that one user with a real password hash is enough to make every account without one reachable.
Cloud images add risk. The official tiny-cloud images from 3.18.11 through 3.24.3 include an alpine user with a "*" field and passwordless doas. They are safe on first boot. They become exploitable once any $6$ hash appears. That can happen when an administrator sets a console password or cloud-init adds a user with hashed_passwd.
Several setups are explicitly safe. These include openssh-server-pam with UsePAM yes, and any setup with PasswordAuthentication no. Accounts locked with "!" in the shadow file are also safe. So are machines where no account has a $5$ or $6$ hash. glibc systems, OpenBSD and Dropbear are not affected by this bug.
Containers deserve a separate note. Docker Hub listed about 12.47 billion pulls for the official Alpine image on 5 November. Alpine says containers that do not run sshd are not exposed. That limits the blast radius despite the image’s popularity. The risk sits on hosts and images that do run the daemon with password authentication enabled.
How does a long password turn into a login?
When sshd is built without PAM, it checks a password with crypt(). That C library function turns a password into its stored hash. sshd then compares the result with the value in the shadow file.
An account with no password stores "*" in that field. The asterisk is not a hash. It is a marker that no real password can match. For an account whose stored field is too short to contain a salt, sshd borrows the salt of another account. That fallback exists to keep response times similar for invalid users.
The fallback traces back to CVE-2016-6210, a timing flaw that let attackers guess which usernames existed. The fix made sshd hash even invalid attempts, so a missing account would not answer faster than a real one. It did not anticipate a libc that returns the same string stored for passwordless accounts.
musl’s crypt() returns "*" when the key is longer than 256 bytes. That string is also the stored value for passwordless accounts. The comparison succeeds, and sshd treats the attempt as a valid login.
Alpine describes the attack in blunt terms. It "takes one connection, works every time, and needs no retries." NVD gives the range as 256 to 1,024 characters, which differs slightly from Alpine’s wording of 257 to 1,024 bytes.
The account does not need to be root. Any reachable account with an asterisk in its password field will do. That includes a deployment user whose key was supposed to be the only credential. If that account has doas or sudo rights, the attacker can escalate. The advisory’s warning is about reachability, not about the name of the account.
The pieces arrived separately. According to the researcher’s write-up, musl added SHA-512 crypt in August 2012 with a 256-byte key limit and returned "*" on failure. OpenSSH added salt borrowing for invalid users in a July 2016 commit. Alpine changed root’s password field from "!" to "*" around version 3.16 in 2022.
Each change made sense on its own. Together they produced a bypass that appears to have gone unnoticed for years. The researcher tested about 17,600 logins across glibc, musl, PAM and non-PAM builds. Every combination behaved the same except musl without PAM.
OpenSSH says it considers "the root cause of this bug to be outside sshd," while accepting that it is exploitable through sshd. The 10.6p2 workaround sits in sshd. Alpine also backported the fix to its stable branches.
How do you fix an affected host?
The shortest path is to upgrade and restart. Run apk upgrade -U -a, then restart sshd with rc-service sshd restart. Upgrading the package does not restart a running daemon, so the restart is not optional.
Fixed openssh versions by branch are: edge 10.6_p2-r0, 3.24 10.3_p1-r2, 3.23 10.2_p1-r1, 3.22 10.0_p1-r11 and 3.21 9.9_p2-r1. Alpine also published fixes for 3.16 through 3.20, even though some of those releases no longer receive regular updates.
If you cannot patch immediately, disable password authentication. Add PasswordAuthentication no to /etc/ssh/sshd_config.d/00-no-passwords.conf, check the configuration with sshd -t, and restart sshd. Keep an existing session open until a key-based login works, so a mistake does not lock you out. Restricting port 22 to known addresses buys time as well.
Detection matters as much as patching. Look in /var/log/messages for "Accepted password for" lines. The account named there may have no password, such as root, alpine or a key-only service user. Review doas use, recently created users, files and authorized_keys on exposed machines. If you cannot rule out a login, treat the host as compromised.
Verification is quick. After the restart, run sshd -T and confirm the effective settings for passwordauthentication and usePAM. A package upgrade alone leaves the old daemon in memory, and a configuration change without a reload has no effect. Check both before you assume a host is fixed.
On a compromised host, rotate credentials that were readable from it. That includes SSH keys stored on disk, cloud metadata tokens and any secrets in environment files. The bug grants a shell, so the attacker could have copied material before you patched.
Teams that build container images should rebuild any image that runs sshd and is based on an affected Alpine release. Cloud instances need the same treatment. Updating a base image tag does not patch a container that is already running.
Why does a niche libc bug matter?
Alpine is popular because its images are small, which makes it a common base for containers, CI jobs and appliances. Many of those workloads never start sshd, so the practical exposure is narrower than the install base suggests.
The hosts that do run sshd are the concern. These include virtual machines, jump boxes, routers built on musl and cloud images that allow console or password access. On those systems, accounts that were assumed to be key-only can suddenly accept any sufficiently long string as a password.
The bug also reverses a common security assumption. Administrators often treat an account with no password as unusable. Here, that state is exactly what makes the account reachable when another account on the machine has a password hash. Passwordless doas then turns a low-privilege login into root.
The CVSS score reflects the prerequisites. An attacker needs a reachable sshd and password authentication enabled. They also need a target account with an asterisk field. A second account on the machine must have a $5$ or $6$ hash. Once those exist, however, the attack is deterministic rather than probabilistic.
The flaw is not limited to Alpine in principle. OpenSSH names any Linux system using musl libc without PAM. The researcher’s write-up points to OpenWrt, Buildroot and Yocto builds. Some of those use Dropbear by default. They are unaffected unless OpenSSH is installed and configured this way.
Patch lag is the practical worry. Alpine has fixed packages ready, but appliances and vendor images often carry older branches that nobody rebuilds. A router or sensor gateway built on Alpine 3.18 may never see apk upgrade. The same applies to long-lived CI runners and demo virtual machines that were set up once and forgotten.
This is not a supply-chain compromise. No malicious code was inserted, and no maintainer account was abused. It is an interaction bug between a libc error convention and an authentication fallback. That is why it survived code review for so long.
What does this say about AI-assisted bug hunting?
OpenSSH’s release notes say the team has received many security reports. Many are findings from AI models or were made with AI assistance. The team says many do not have security impact under a realistic threat model. It still welcomes reports that come with human triage, test cases and fixes.
Damien Miller, an OpenSSH maintainer, wrote that the team learned of this problem the day before release. He cited "multiple cases of rapid bug rediscovery by AI agents, sometimes within hours." He argued that long embargo periods now mainly benefit attackers.
That explains the fast point release and Alpine’s same-day packages. It also signals a change in disclosure practice. Expect more frequent small releases, shorter embargoes and more pressure on downstream distributions.
AI-generated reports also add noise. OpenSSH says many submissions do not survive scrutiny. The useful ones tend to include analysis and a proposed fix, not just a claim that something looks wrong. Human maintainers still decide what matters.
For downstream projects, the lesson is to shorten the gap between an upstream fix and a packaged update. Alpine did that within a day, including for branches it no longer supports. Distributions that wait for a monthly cycle leave a window that attackers can scan for.
No exploitation in the wild had been reported when Alpine published its advisory, and no public exploit code had been released. The CVE record was published the same day. Those facts may change, so exposed hosts should be patched first and investigated second.
For readers on a laptop or a standard cloud image, the practical advice is unchanged. Keep password authentication off and patch promptly. The difference here is that the affected hosts were often configured to be more secure than average. Key-only access removed the password, but not the entry path.
Watch for scanning activity against SSH ports and updates from other musl-based platforms. A change to musl’s crypt() behaviour upstream would also matter. A CVE entry or a distributor advisory is not the end of the story; the running daemon is what matters.