As reported by BleepingComputer, a newly disclosed vulnerability dubbed "*sshole" exposes a subtle but dangerous interaction between OpenSSH's authentication logic and the musl C library's crypt() implementation. The result: attackers can authenticate to accounts explicitly configured to reject password logins — including default accounts in Alpine Linux's official AWS and Azure cloud images that carry passwordless doas (a sudo alternative) privileges.
Why This Matters
This is not a typical authentication bypass. It is a semantic collision — two independently reasonable design decisions that, when combined under specific conditions, produce an exploitable security hole. OpenSSH's 2016 patch for CVE-2016-6210 introduced dummy hashing for accounts with unusable password hashes to prevent timing-based username enumeration. musl's crypt() returns * when it encounters a password exceeding its 256-byte input limit. When an account's stored hash is also * (the conventional way to disable password login), the comparison succeeds trivially.
The vulnerability has existed since 2016 and remained undetected for a decade — a stark reminder that complexity in authentication chains creates blind spots that even mature projects miss.
Affected Products and Conditions
| Attribute | Detail |
|---|---|
| Vulnerability Name | *sshole |
| Root Cause CVE | CVE-2016-6210 (OpenSSH timing patch) |
| Severity (Shield53 Assessment) | High — authentication bypass with potential root escalation |
| Affected C Library | musl libc (NOT glibc) |
| Affected Distributions | Alpine Linux, OpenWrt, Buildroot, Yocto (and any musl-based distro) |
| Not Affected | Debian, Ubuntu, Fedora, RHEL (glibc-based); any system using PAM authentication |
| Exploitation Conditions | PAM disabled + SSH password auth enabled + ≥1 account with * hash + ≥1 account with valid hash |
| Cloud Image Exposure | Alpine Linux official AWS and Azure images ship vulnerable 'alpine' account with passwordless doas |
| Active Exploitation | Not yet observed (disclosed November 5, 2026) |
| Patch Availability | Pending — check vendor advisories |
Who Is Most at Risk
The exposure profile is narrower than it first appears but includes some high-value targets:
alpine user has passwordless doas access. An attacker who exploits *sshole on this account can pivot directly to root.*, the bypass applies.The good news: most enterprise Linux deployments use glibc (Debian, Ubuntu, RHEL, Fedora) and are inherently immune. The risk concentrates in lightweight, musl-based environments — which are disproportionately used in cloud-native, edge, and embedded scenarios where patching cycles are slower and exposure can be permanent.
Broader Implications
This vulnerability highlights an underappreciated class of risk: cross-component semantic flaws. Neither OpenSSH nor musl is individually buggy. The OpenSSH team's 2016 mitigation was sound for glibc systems. The musl team's crypt() return value is a reasonable design. But when combined under the specific configuration conditions present in Alpine's default setup, they create an exploitable path.
It is also notable that the researcher, Ozgun Kultekin, discovered this through AI-assisted fuzzing of authentication configurations — running ~17,600 test cases across malformed hashes and oversized passwords. This suggests that AI-driven security testing can surface interaction-level bugs that traditional vulnerability scanning and manual code review have consistently missed for a decade.
Shield53 Recommendations
Immediate Actions
- Inventory and identify exposed assets: Search your environment for musl-based Linux hosts with SSH exposed. Prioritize Alpine Linux instances deployed from AWS or Azure Marketplace images. Run
ldd $(which sshd) | grep muslor check/lib/ld-musl-*.so.1to confirm the C library. - Audit the 'alpine' account: On Alpine cloud images, immediately check whether the
alpineuser exists and has*in/etc/shadowwith passwordlessdoas. If so, treat this as a live root-exposure risk. - Disable SSH password authentication: Set
PasswordAuthentication noinsshd_configand rely exclusively on key-based authentication. This eliminates the attack path entirely. - Enable PAM authentication: If password auth must remain enabled, configure OpenSSH to use PAM (
UsePAM yes). PAM-based authentication is not affected by this flaw. - Replace
*hashes with!: In/etc/shadow, change disabled-account hashes from*to!as an interim mitigation. Verify this does not break any dependent services. - Restrict SSH access: Use security groups, firewall rules, or
AllowUsers/AllowGroupsdirectives to limit SSH exposure to trusted management IPs only. - Monitor for exploitation: Watch SSH logs for authentication events involving oversized passwords or successful logins to accounts that should be locked. Any successful auth on a
*-hashed account is a strong indicator of compromise.
Longer-Term Actions
- Track for patches: Monitor OpenSSH and Alpine Linux security advisories for upstream fixes. Given the root-escalation potential on default cloud images, expect a rapid patch cycle.
- Reassess musl-based deployments: For organizations running Alpine in production, evaluate whether the lightweight footprint justifies the added risk surface from musl-specific interaction bugs. Consider glibc-based minimal images (e.g., Debian slim) where operational constraints allow.
- Adopt AI-assisted configuration fuzzing: Kultekin's methodology — systematic testing of authentication interactions across malformed inputs — is reproducible. Security teams should consider similar approaches for critical authentication components.
