Critical OpenSSH Flaw Allows Login to Password-Disabled Linux Accounts

Executive Summary

A critical authentication bypass vulnerability, known as "sshole," affects OpenSSH deployments on musl-based Linux systems. The flaw can allow attackers to authenticate to accounts configured to reject password-based logins by submitting an oversized password. Affected environments include Alpine Linux, OpenWrt, Buildroot and Yocto-based systems where specific authentication conditions are present. Organisations should review exposed SSH services and apply the appropriate security updates or mitigations.

Key Details

Affected Platform

OpenSSH on musl-based Linux systems.

Attack Surface

SSH password authentication on systems without PAM.

Recommended Action

Identify vulnerable configurations and apply the relevant OpenSSH security fixes.

Affected Environment

The vulnerability affects OpenSSH deployments on musl-based operating systems, including Alpine Linux, OpenWrt, Buildroot and Yocto-based environments.

Exploitation requires a specific combination of conditions: PAM authentication must be disabled, SSH password authentication must be enabled, at least one account must use an asterisk (*) as its stored password hash, and another account must have a valid password hash.

Accounts with valid password hashes are not directly bypassed by this flaw.

Operational Impact

Successful exploitation may allow an unauthorised attacker to access a Linux account that administrators intended to disable for password-based authentication.

Depending on the permissions assigned to the compromised account, attackers could gain access to sensitive files, modify configurations or establish a foothold for further activity. Systems exposing SSH services to untrusted networks warrant particular attention.

Technical Root Cause

The vulnerability arises from an interaction between OpenSSH authentication handling and the musl C library's crypt() function.

On affected systems, passwords exceeding 256 bytes cause crypt() to return an asterisk (*) rather than a valid password hash. Because Linux accounts with disabled passwords may also store an asterisk in /etc/shadow, the authentication comparison can incorrectly succeed.

The behaviour is linked to OpenSSH changes introduced in 2016 to address username enumeration under CVE-2016-6210. That historical CVE should not be treated as the identifier for the newly reported authentication bypass.

Recommended Mitigation

Apply the relevant OpenSSH and operating-system security updates.
Audit musl-based systems for vulnerable authentication configurations.
Disable SSH password authentication wherever operationally feasible.
Restrict SSH access to trusted networks and authorised users.
Review accounts using disabled-password markers.
Enforce least-privilege access.
Monitor SSH authentication logs for unusual login attempts.
Maintain current endpoint and perimeter security protections.

Concerned about your exposure?

Our security experts can help you assess affected systems, validate risk and support a safe remediation plan.

Discuss Your Security Exposure Close Critical Security Gaps Before Attackers Find Them

Assess your risk

Identify affected systems

Plan remediation

Practical, vendor-aligned guidance

Get expert support

From our 24/7 security team

Stay ahead of emerging threats

Get the latest threat intelligence and security advisories from Smarttech247.

Full Technical Report

Download the complete analysis, including detailed technical findings and references.

Download Full Report (PDF)

References

BleepingComputer — OpenSSH authentication flaw

GitHub — SSHole proof of concept