SSHole CVE-2026-123158: How an Oversized Password Turns a Shadow File Asterisk Into an OpenSSH Login

What Is SSHole CVE-2026-123158?

SSHole CVE-2026-123158 is a high-severity authentication bypass in OpenSSH’s sshd. Its CVSS v3.1 base score is 8.1 (High).

The vulnerability affects specific Linux configurations using musl without PAM. Password authentication must also be enabled, and particular account conditions must exist.

Alpine Linux’s default openssh-server package is built without PAM. Therefore, Alpine systems with the required account and authentication settings can be vulnerable.

Özgün Kültekin of Wakefield discovered the vulnerability and named it SSHole. Unlike memory-corruption vulnerabilities, SSHole results from two existing implementation behaviors: one in OpenSSH and another in musl.

SSHole Vulnerability Details

How Does SSHole CVE-2026-123158 Exploit musl’s crypt()?

SSHole exploits how musl handles password-hashing errors. When processing oversized passwords with valid SHA-256-crypt or SHA-512-crypt settings, musl returns *.

Without PAM, sshd hashes submitted passwords using crypt() and compares the result against the stored password field for local accounts. Consequently, musl’s error response can match an existing * shadow entry.

Alpine also identifies directory-service identities resolved through musl-nscd without local shadow entries as potentially affected.

OpenSSH’s 2016 Authentication-Timing Workaround

In 2016, OpenSSH introduced fallback password hashing to mitigate username-enumeration timing differences associated with CVE-2016-6210.

For nonexistent accounts, sshd enumerates system account entries using setpwent() and getpwent(). It selects the salt from the first account whose stored password field begins with $ and contains another $ delimiter. This is a structural check, not full cryptographic validation of the stored hash.

This fallback also affects real accounts with * password fields. For SSHole, the selected account’s hash must use SHA-256-crypt ($5$) or SHA-512-crypt ($6$).

musl’s crypt() Error Handling

Since 2012, musl has rejected SHA-256-crypt and SHA-512-crypt password inputs longer than 256 bytes.

When both values are *, the comparison can succeed and allow authentication.

An attacker who knows the target username can submit a password between 257 and 1,024 bytes. The failed hash returns *, potentially matching the account’s shadow entry.

Alpine’s advisory describes exploitation through one SSH connection without connection retries. However, an independent source-level reproduction found that the first password attempt failed. The second succeeded within the same connection.

Kültekin tested sshd builds across glibc and musl, with and without PAM. The tests involved approximately 17,600 unusual login attempts. Only the tested musl builds without PAM accepted logins that should have been rejected.

These implementation behaviors explain how SSHole works. However, actual exposure depends on how organizations deploy and configure OpenSSH across their Linux systems.

Which Alpine and musl Systems Are Vulnerable to SSHole?

SSHole affects specific OpenSSH configurations rather than every Linux system using musl. Administrators should evaluate the SSH configuration, account database, and password-hashing behavior together.

Alpine Linux

Alpine’s default openssh-server package is built without PAM. Its openssh-server-pam variant is affected when UsePAM no is configured.

An Alpine host is potentially vulnerable when password authentication is enabled and the target is an account with * in its shadow password field or an affected directory-service identity resolved through musl-nscd without a shadow entry.

Also verify that OpenSSH’s selected fallback hash meets the $5$ or $6$ requirement.

Alpine Cloud Images

Official Alpine tiny-cloud images (qcow2, VHD, and AMI) from versions 3.18.11 through 3.24.3 include an alpine user with a * password field and passwordless doas.

These images are safe on first boot. They become exploitable when another local account introduces a SHA-512-crypt ($6$) password hash. This can happen when an administrator sets a console password or user-data adds an account with hashed_passwd.

The default PermitRootLogin prohibit-password setting blocks direct root password authentication over SSH. However, attackers who authenticate as the alpine user can still obtain root privileges through its passwordless doas permissions.

Cloud images configured through cloud-init are not affected by default because cloud-init writes PasswordAuthentication no.

Other musl-Based Systems

OpenWrt, Buildroot, and Yocto images may also be exposed, depending on their OpenSSH and libc configurations.

OpenWrt uses Dropbear by default, which is not affected. However, its musl-based builds can use the openssh-server package without PAM or the separate openssh-server-pam variant.

Evaluate the installed package, libc implementation, and effective PAM configuration before determining exposure.

Container Images

Containers running a reachable OpenSSH daemon built with musl and without PAM are potentially exposed.

However, exploitation also requires password authentication to be enabled, a target account with a * password field or an affected directory-service identity, and at least one local account with a SHA-256-crypt ($5$) or SHA-512-crypt ($6$) password hash. Containers without a reachable SSH service are not exposed through this attack path.

Systems Not Affected

The following configurations are outside the documented vulnerable scope:

• Standard glibc-based Debian, Ubuntu, and Fedora installations.
• OpenSSH configurations using PAM with UsePAM yes.
• Dropbear-based SSH services.
• Native OpenBSD systems.

What Did Previdian and GreyNoise Observe After Disclosure?

Previdian reported its first observed exploitation attempt approximately eight hours after CVE publication.

Previdian’s founder told The Hacker News that the company had confirmed root access on an Alpine Linux honeypot.

Separately, Previdian’s public sensor telemetry documents observed attempts rather than independently establishing successful exploitation.

The founder also reported that activity from the source IP involved oversized passwords and non-interactive SSH sessions. The sessions executed commands such as id, uname, and hostname.

Initial reporting counted eight attempts from one Japan-based IP address. By November 9, Previdian had recorded 20 attempts from 13 IP addresses across nine countries. Its four sensors observed this activity.

What Did GreyNoise Confirm?

Observed activity included root-level command execution and unauthorized modifications to SSH authorized_keys files.

One attacker also uploaded a Python-based C2 agent and attempted to enroll it. However, enrollment failed, and the agent received no tasks.

Public reporting has not established successful data exfiltration or lateral movement to other systems.

Separately, Previdian cautions that available GitHub proof-of-concept samples are unverified and may contain malware.

How to Patch SSHole CVE-2026-123158

The primary remediation is upgrading to OpenSSH 10.6p2 or an equivalent patched distribution package.

Update Alpine Packages

Alpine’s security advisory lists fixed packages for:

Alpine also published fixes for older branches, extending back to 3.16.

Check the advisory for the exact package version applicable to each branch. Patched Alpine packages may carry version numbers older than upstream OpenSSH 10.6p2.

Consequently, scanners that compare only against the upstream version may incorrectly flag patched installations.

Restart Running SSH Services

On Alpine Linux, installing the OpenSSH update does not automatically restart a running sshd process. Restart the service after upgrading to ensure the patched binary is running. On other distributions, verify whether the package update restarted the service.

Rebuild Container Images

Rebuild and redeploy container images containing vulnerable OpenSSH packages.

Alpine releases before 3.16 have no fixed packages listed in the advisory. Administrators should migrate to a release containing the fix or rebuild with patched OpenSSH 10.6p2 or an equivalent backport.

Apply Interim Mitigations

OpenSSH developer Damien Miller advised disabling SSH or setting PasswordAuthentication no on affected systems until they are patched.

After changing the SSH configuration, restart sshd to apply the setting.

Checking Alpine Hosts for Signs of an SSHole Login

Patching addresses the vulnerability, but administrators should also investigate previously exposed hosts.

On unpatched Alpine hosts, search /var/log/messages for sshd entries containing Accepted password for.

Pay particular attention to accounts intended for key-based authentication only, including alpine and other restricted accounts. Also review root authentication where PermitRootLogin yes is configured. The default PermitRootLogin prohibit-password setting blocks direct root password authentication, although attackers may still obtain indirect root privileges through accounts with passwordless doas permissions.

On other affected distributions, inspect configured authentication logs or the system journal for equivalent events.

Also review:

• doas activity and unexpected privilege escalation.
• Recently created user accounts.
• Changes to authorized_keys files.
• Unexplained successful password-authentication events.

If unauthorized access cannot be ruled out, treat the host as potentially compromised and investigate accordingly.

These investigation requirements also highlight the importance of understanding which Linux distributions fall outside an organization’s automated patch-management coverage.

Featured resource

Simplify Patch Management with Hexnode UEM

Explore how Hexnode UEM helps IT teams monitor patch status and manage manual and automated updates across supported Linux distributions.

Download the One-pager

Where Hexnode UEM’s Linux Patching Stops Short of Alpine

Hexnode’s October 2026 product announcement identifies Ubuntu 18.04 LTS and later, Linux Mint 21 and later, Debian 10 and later, and Fedora 36 and later as supported Linux patch-management distributions. However, its detailed automated and manual deployment guides currently list only Ubuntu, Linux Mint, and Fedora.

The Linux Agent uses APT and DNF for package-management workflows. Alpine Linux is not included in the published support lists.

The Linux patch-management documentation does not specify whether Hexnode’s workflows inspect libc implementations, effective PAM settings, or custom OpenSSH builds. Administrators should validate these configurations separately when assessing SSHole exposure.

Hexnode’s Linux Live Terminal and general Execute Custom Script documentation list Debian, Fedora, and Ubuntu as supported distributions. A separate Linux system-log script guide lists additional distributions, including Linux Mint, Kali, RHEL, CentOS, AlmaLinux, and Rocky Linux, in its script-specific compatibility requirements. Confirm support for these additional distributions before treating them as generally supported Hexnode remote-execution platforms.

How Should Organizations Respond to SSHole CVE-2026-123158?

Organizations should inventory Alpine and other musl-based systems running OpenSSH without PAM. Verify password authentication, affected account states, and the fallback hash selected by sshd.

Prioritize affected systems for patching. Until updates are installed, disable password authentication and restart sshd. Finally, review authentication logs, privilege-escalation activity, and SSH key changes on previously exposed hosts.