SSHole: the bug that unlocks any password-less Linux account

The discovery and public exploitation of an authentication bypass vulnerability in OpenSSH — dubbed SSHole and tracked as CVE-2026-123158 — has exposed a flaw that lay dormant for a decade, since 2016. Scoring 8.1 on the CVSS scale (High), the vulnerability affects exclusively OpenSSH servers running on Linux distributions based on the musl libc library without the Pluggable Authentication Modules (PAM) framework enabled — the typical case for Alpine Linux and countless container images. CISA has already catalogued the vulnerability as being actively exploited in the wild and imposed a remediation deadline of November 12 for U.S. federal agencies.

How the flaw works

The mechanics of SSHole are elegant in their simplicity. Server administrators routinely configure service accounts by blocking password login — simply replacing the password hash in `/etc/shadow` with an asterisk (``). That account should never accept a password login, since `` does not represent a valid hash.

The problem traces back to a 2016 patch intended to fix CVE-2016-6210, a username enumeration vulnerability. To prevent attackers from identifying valid usernames through different response times, OpenSSH was modified to perform password hashing even when the account lacked a usable password hash — including accounts configured with `*`.

Here lies the conflict: the `crypt()` function in the musl libc library returns `*` when hashing fails, including when the submitted password exceeds its 256-byte limit. OpenSSH, in turn, compares the value returned by hashing against the asterisk stored in `/etc/shadow`. The result: the login succeeds. Any password between 257 and 1,024 characters functions as a master key.

Researcher Ozgun Kultekin, who discovered and disclosed the vulnerability, notes that exploitation requires five simultaneous conditions: OpenSSH on a musl system, PAM disabled, password authentication enabled, at least one account with a `*` hash, and another account with a valid hash (`$5$` or `$6$`). With that, compromising a single password-enabled account makes all password-less accounts reachable.

What is actually affected

The impact is most severe in cloud and IoT environments. Alpine Linux's official tiny-cloud images (qcow2, VHD, and AMI) from versions 3.18.11 through 3.24.3 ship with an `alpine` user whose password field is `*` and who has passwordless `doas` privileges. On first boot, they are safe. The moment any administrator sets up a user with a password, the machine becomes exploitable. An attacker gains a shell as `alpine` and uses `doas` to become `root`.

Systems based on glibc — Debian, Ubuntu, Fedora, Red Hat, SUSE — are unaffected, since the glibc implementation of `crypt()` does not return `*` under the same conditions. Likewise, systems using PAM are protected, as the PAM authentication chain intercepts the request before the OpenSSH bug can manifest.

Kultekin discovered the flaw using artificial intelligence agents that executed approximately 17,600 authentication tests with different OpenSSH configurations, malformed password hashes, and oversized passwords — a telling example of how AI-driven automation is being employed both to discover and, presumably, to exploit vulnerabilities.

Active exploitation and attack scale

The first exploitation attempts were recorded on November 5, 2026, immediately following public disclosure of the patch and proof-of-concept code. On the morning of November 6, watchTower, an offensive security firm, observed attacks associated with botnets and cryptocurrency miners. By November 9, Previdian had logged 22 successful exploits from 14 unique IP addresses across 9 countries.

CISA added the vulnerability to its Known Exploited Vulnerabilities (KEV) catalog on November 9, classifying it as confirmed exploitation in a live environment. The remediation mandate for U.S. Federal Civilian Executive Branch agencies is November 12 — just three days after listing — one of the shortest deadlines ever set by the agency.

Alongside the KEV listing, CISA invoked Forensics Triage Requirements, suggesting that affected entities should investigate whether their environments have already been compromised. Detection tools like Google's Goonam Scanner are already being used to scan for exposed assets at scale.

Mitigation and remediation

OpenSSH 10.6p2, released on November 5, definitively fixes the issue. The corrected Alpine Linux package versions are:

- Alpine 3.21.10 - Alpine 3.22.8 - Alpine 3.23.8 - Alpine 3.24.4

Administrators who cannot immediately update should disable password authentication:

``` PasswordAuthentication no ```

Then restart the `sshd` daemon.

To check for possible compromise on Alpine Linux, run:

``` grep "Accepted password" /var/log/messages ```

If the log shows a successful password login for a password-less account (like `alpine`, `root`, or any key-only user), treat the machine as compromised. Review `doas` usage, recently created users, suspicious files, and unauthorized SSH keys in `/root/.ssh/authorized_keys`.

What this flaw reveals about Linux ecosystem security

SSHole exposes two structural problems in the open-source ecosystem. First, the fragmentation of C libraries — musl vs. glibc — creates attack vectors that slip past conventional testing, since the vast majority of researchers and audit tools operate in glibc environments. Second, the discovery of a decade-old vulnerability via automated AI-driven testing signals a paradigm shift: agent-driven penetration testing is becoming a real and accessible threat. If AI agents can uncover flaws like this in 17,600 attempts, it is not difficult to imagine that the same agents — or their adversaries — are exploiting those very flaws simultaneously.

The question that remains: when autonomous security agents become as common as malicious ones, will the race between detection and exploitation be won by defenders?

---

Sources: BleepingComputer (Nov. 9, 2026), SecurityWeek (Nov. 6, 2026), CVE Details (CVE-2026-123158), Alpine Linux Security Advisory (Nov. 5, 2026)

Sources: BleepingComputer, SecurityWeek, Alpine Linux, CVE Details

✓ Independent sources cross-checked and verified before publishing