Attackers have started exploiting “SSHole,” a newly disclosed OpenSSH password-authentication bypass, turning what could have been dismissed as a niche configuration bug into a live control-plane problem for some Linux fleets. As SecurityWeek reported, sensors operated by Previdian saw 20 exploitation attempts from 13 unique IP addresses across nine countries between Nov. 6 and 8, just days after a fix was released.
Why that matters is not that every SSH server is suddenly open. It is that a bounded set of systems can expose exactly the kinds of accounts administrators often assume are safe from passwords: key-only accounts, appliance logins, and operational access points that sit at the center of cloud, networking, build, and backup infrastructure.
For most organizations, the real question is simple: do any of our servers actually meet the musl, PAM, password, and account conditions for SSHole, and if we updated, did we restart the daemon that is still deciding who gets in?
What actually makes a server vulnerable
The answer starts with scope. In OpenSSH’s Nov. 5 release notes, the project described the change as a critical security workaround affecting some Linux systems built and run with musl libc and with PAM support disabled. This is not a universal flaw in every OpenSSH deployment.
The configuration details matter. Alpine Linux’s advisory says the risky combination includes its openssh-server package, or openssh-server-pam with `UsePAM no`, with `PasswordAuthentication` enabled, at least one account whose shadow field is exactly `*`, and at least one other local account with a `$5$` or `$6$` password hash. In that setup, an attacker can authenticate to certain accounts using an arbitrary very long password; SecurityWeek described the trigger range as 257 to 1,024 characters.
The mechanism is technical but important because it explains why the bug is easy to misread. When sshd checks a password for an account whose stored field is `*`, the affected path can borrow a salt from another account’s password hash. For passwords longer than 256 bytes, musl’s `crypt()` can return `*` rather than a failed comparison. If sshd then treats that result as matching the target account’s `*` field, an account that was meant to be unusable for password login may start accepting one.
That makes SSHole a configuration-and-runtime problem, not just a version problem. Systems using glibc are not affected through this path. Systems using PAM with `UsePAM yes` are not affected through this path. Systems with password authentication disabled are not affected through this path. Containers that include a vulnerable package but do not run sshd are not remotely exposed through this issue. On the other hand, bastions, cloud images, appliances, and edge devices built on musl can remain exposed if all the conditions line up.
Why package inventory is not enough
This is where business risk enters the story. SSH is a control-plane service: the route into production instances, CI runners, network appliances, backup servers, and the admin boxes used to reach everything else. A password login to a supposedly key-only account can become the first move in a larger chain, from adding `authorized_keys` for persistence to data theft, cryptomining, or lateral movement.
The early activity SecurityWeek described was linked to botnets and crypto miners, which is typical for fast-moving opportunistic exploitation. That should not be read as a ceiling on the threat. The value of a working SSH foothold rises quickly once a more capable actor finds an exposed bastion or an appliance with broad network reach.
At the same time, the public evidence does not support panic. The observed attempts do not prove successful compromise. They do not show global prevalence. Cloudflare’s technical coverage noted a CVSS 3.1 score of 8.1 and said CISA’s assessment includes a public proof of concept, while also saying CISA does not consider the attack automatable. That is a useful framing: exposed hosts are attractive, but this is not evidence of an internet-scale, hands-off worm.
The bigger operational trap is false closure. Alpine warned that upgrading the package does not replace the running sshd process. An installed fix is not the same thing as a running fix. That distinction matters especially in environments where teams rely on package inventory dashboards, golden images, or vulnerability scanners that track installed software more readily than long-lived daemons.
It also matters because Alpine and other distributions backport fixes. A server can be protected while still showing an older-looking package version, depending on the branch. Alpine listed fixed packages including 10.3_p1-r2 for Alpine 3.24, 10.2_p1-r1 for 3.23, 10.0_p1-r11 for 3.22, plus backports for older supported branches. Treating upstream 10.6p2 as the only safe version would miss that packaging reality.
A four-part audit that answers the real question
For security and infrastructure teams, the most useful response is a short audit rather than a blanket assumption.
1. Identify hosts that actually run sshd. Start with internet-facing systems, operations bastions, cloud images, appliances, and unmanaged edge gear. Separate them from containers or images that merely contain OpenSSH packages but do not expose an SSH service.
2. Establish whether the host uses musl and how PAM is configured. Alpine is the obvious first place to look, but the same risk model can extend to other musl-based distributions or builds, including Buildroot, OpenWrt, and Yocto, when the relevant conditions are present.
3. Inspect effective SSH and account conditions, not just defaults. Check whether `PasswordAuthentication` is enabled anywhere in the active configuration, including through `Match` blocks. Then verify whether there is at least one local account with a shadow field exactly equal to `*` and at least one other account using a `$5$` or `$6$` hash. That combination is what turns the bug into an exposure.
4. Upgrade to the fixed package and restart sshd. Alpine’s fallback mitigation, if an update cannot happen immediately, is to set `PasswordAuthentication no` and restart sshd after confirming key access. That is a strong emergency step, but it is not free of operational risk: legacy automation and poorly documented access paths can break if teams have not tested their keys.
Afterward, review logs for successful password logins to accounts that were expected to have no usable password. That will not answer every forensic question, but it is the fastest way to look for the specific failure mode SSHole creates.
One unresolved issue is where the longer-term fix should ultimately live. OpenSSH describes its change as a workaround because the root cause sits in the interaction with musl, while musl maintainer commentary assigns responsibility differently. That debate matters for future hardening and packaging. For defenders this week, though, the decision is more immediate: prove that exposed systems do not meet the vulnerable conditions, or prove that the fixed sshd has been restarted and password access is closed where it should be.
By
By
By
By
By
