A critical authentication bypass flaw in OpenSSH is facing active exploitation less than nine hours after its disclosure, according to telemetry reported by cybersecurity researchers. The vulnerability allows remote attackers to access passwordless accounts on Alpine Linux and other musl-based operating systems with a single connection and no prior credentials.

The issue, tracked as CVE-2026-123158 and nicknamed "sshole" by Wakefield researcher Özgün Kültekin, was addressed in OpenSSH version 10.6p2 on November 5. As detailed by Help Net Security, threat intelligence firm Previdian observed threat actors actively targeting the bug, confirming that an adversary obtained root access on an exposed honeypot.

Active Exploitation in the Wild

Previdian founder Ryan Dewhurst revealed that the firm's monitoring infrastructure registered attacks originating from a single Japan-based IP address, 89.116.89[.]18. The sensor recorded eight distinct attempts, with the first detected shortly after the vulnerability was made public.

During the recorded break-in, the attacker supplied an oversized password to bypass SSH authentication. Once connected, the threat actor initiated non-interactive SSH sessions to run basic system reconnaissance utilities, including id, uname, and hostname. Dewhurst noted that the trivial nature of the flaw, coupled with potential assistance from automated tools, significantly shortened the time between disclosure and real-world attacks.

Previdian has added the flaw to its internal catalog of known exploited vulnerabilities, though the Cybersecurity and Infrastructure Security Agency has not yet added it to the federal KEV list.

How the Authentication Bypass Works

The flaw is the result of an unintended interaction between long-standing code behaviors in OpenSSH and the musl C library. On affected systems, accounts configured without passwords—such as SSH key-only deployment accounts or default cloud users—typically store an asterisk (*) in the password field of the /etc/shadow file.

In 2016, OpenSSH developers modified the SSH daemon to mitigate a user enumeration timing attack (CVE-2016-6210). When a targeted account lacks a usable password hash, sshd borrows a salt from another local account and computes a hash anyway to prevent timing discrepancies. However, the crypt() function in the musl C library has refused SHA-256 and SHA-512 passwords exceeding 256 bytes since 2012. When musl's crypt() fails, it returns a literal asterisk.

Because the output of the failed calculation is an asterisk, OpenSSH compares it against the asterisk stored in /etc/shadow. Finding an exact match, the daemon validates the authentication attempt. Consequently, any string exceeding 256 characters functions as a valid password for accounts that should reject password logins entirely.

Affected Environments and Systems

The vulnerability impacts OpenSSH versions prior to 10.6p2 running on Linux distributions that use the musl C library without Pluggable Authentication Modules (PAM). In addition to standard Alpine Linux installations, musl-based builds such as OpenWrt, Buildroot, and Yocto, alongside numerous musl-derived Docker container images, are susceptible.

For an attack to succeed, password authentication must be permitted in the server configuration, an account with an asterisk in its password field must exist, and at least one other local account on the host must possess a standard password hash. The threat landscape includes cloud deployments: official Alpine images for Amazon Web Services and Microsoft Azure feature a default user named alpine with passwordless administrative permissions through doas. Security firm SOCRadar pointed out that affected tiny-cloud images range from versions 3.18.11 to 3.24.3.

Operating systems utilizing glibc, including Debian, Ubuntu, and Fedora, are completely immune. Setups using PAM, Dropbear SSH, and native OpenBSD environments are likewise unaffected.

What You Should Do

Defenders managing musl-based Linux distributions should immediately evaluate their SSH configurations and apply available vendor patches. Alpine Linux has already released updated packages across supported releases from version 3.16 to edge.

  • Update OpenSSH: Upgrade packages to OpenSSH 10.6p2 or the vendor-supplied patched package. Administrators must ensure the SSH daemon service is restarted immediately, as updating files on disk does not terminate running vulnerable processes.
  • Disable password authentication: OpenSSH developer Damien Miller urged administrators who cannot immediately patch to set PasswordAuthentication no in sshd_config or shut down external SSH access altogether.
  • Review authentication logs: Inspect /var/log/messages and relevant audit logs for Accepted password for events tied to accounts intended to be key-only, root, or default users like alpine.
  • Audit local administrative state: Check system configurations for unexpected changes to doas or sudo permissions, recently created local accounts, and alterations to user authorized_keys files. If unauthorized logins are identified, treat the host as fully compromised.
  • Avoid untrusted exploits: Researchers warn that proof-of-concept scripts proliferating on platforms like GitHub remain unverified and could contain malicious payloads.