*sshole: OpenSSH Password Authentication Bypass on musl Systems Without PAM

1. Basic Information

• Article Title: *sshole: password authentication bypass: OpenSSH + musl libc
• Publisher: Özgün Kültekin / Wakefield
• Publication Date: 2026-11-05
• Original Source: Özgün Kültekin / Wakefield
• Related Sources: OpenSSH 10.6p2 release notes, BleepingComputer: OpenSSH authentication bypass, oss-sec disclosure, Alpine Linux security advisory, OpenSSH fix
• Related Malware: None identified
• Related Threat Actor: None identified
• Related CVE: CVE-2026-123158
• Affected Products: Unpatched OpenSSH before 10.6p2 on affected musl-based Linux configurations without PAM authentication. Examples include relevant Alpine Linux, OpenWrt, Buildroot, and Yocto deployments.
• Severity: High

2. Executive Summary

The authentication bypass known as *sshole affects specific OpenSSH configurations using musl libc without PAM authentication.

For certain password-hashing algorithms, musl's crypt() returns * when a password exceeds 256 bytes. Vulnerable OpenSSH password-checking logic can compare that error value with a target account's stored * field and accept the match.

Exploitation requires password authentication to be enabled, a login-permitted target account with a * password field, and a suitable salt borrowed from another account's $5$ or $6$ hash. Under those conditions, a password of 257–1024 bytes can authenticate without the account's legitimate credentials.

OpenSSH 10.6p2 and vendor backports address the problem. Updating package files alone is insufficient: restart the running sshd.

3. Attack Flow

Authentication Bypass Mechanism

1. An attacker reaches an affected SSH server and supplies the name of an account whose password field is *.
2. Password authentication is enabled, PAM is not handling the check, and the account passes the server's other login restrictions.
3. OpenSSH borrows a salt from another account for its timing-related password-checking behavior. The relevant borrowed format is $5$ or $6$.
4. For an input of 257–1024 bytes, musl's relevant hashing implementation returns the error string *.
5. Vulnerable OpenSSH logic compares that value with the target's stored * and accepts authentication.
6. If the resulting account also has passwordless doas or sudo privileges, the attacker may proceed to root-level operations.

Input and Account Conditions

The bypass rows below assume that the other required configuration and login conditions are satisfied.

4. Threat Actor Location and Execution Site

• Attacker Position: A remote attacker able to connect to the SSH service.
• Required Knowledge: The attacker needs to identify or guess a suitable account name and reach an affected configuration.
• Initial Credentials: No legitimate password is required for the bypass.
• Login Restrictions: Account and SSH access restrictions still apply. For example, PermitRootLogin prohibit-password prevents direct root password login through this route.
• Follow-On Privileges: Root access through another user depends on that user's actual doas, sudo, or other privileges.

5. Victim and Administrator Visibility

• Account Owner: The owner may receive no immediate visible warning that another session has authenticated.
• Administrator: Authentication records may contain Accepted password for an account whose stored field is * and which was intended not to accept passwords.
• Follow-On Activity: Process or audit records may show a shell, doas or sudo, file changes, or other actions, depending on the logging configuration.
• Log Location: Alpine's advisory points to /var/log/messages. The path, retention, and availability of authentication records depend on the system.

A successful authentication record does not, by itself, prove root escalation.

6. Success and Failure Conditions

Success Conditions

All of the following are required:

• An unpatched OpenSSH server uses musl libc.
• PAM does not handle the password check, because PAM is disabled or the build lacks PAM support.
• The effective configuration enables PasswordAuthentication.
• The target account's password field is *, and the account is permitted to log in.
• The borrowed salt comes from another account with the relevant $5$ or $6$ hash format.
• The supplied password is 257–1024 bytes long.

Conditions That Stop This Bypass

• OpenSSH 10.6p2 or a vendor package with the fix is installed, and the running sshd has been restarted.
• Password authentication is disabled in the effective configuration.
• The required target account or suitable salt source is absent.
• The deployment uses a non-affected authentication path or implementation.

Configuration Comparison

Alpine's tiny-cloud images should not be described as uniformly exploitable on first boot. The advisory explains that the additional hash condition must also be met. Once it is, a default user with passwordless doas can provide a path to root.

7. What Happens Upon Success

• The attacker authenticates as the target account without knowing a legitimate password.
• An interactive shell or other allowed SSH session may become available, subject to the account's session restrictions.
• Passwordless doas or sudo can provide a subsequent route to root where configured.

The password bypass and root escalation are separate stages.

8. Observable Logs

The following are possible investigation sources. Their presence depends on collection settings.

• Email: No email-specific evidence is associated with this mechanism.
• Proxy / SWG / DNS: No specific proxy or DNS indicator is required.
• Endpoint / EDR: SSH authentication success followed by session processes, shells, doas, sudo, or file changes.
• Identity / IdP: Local SSH authentication is generally recorded by the host rather than a cloud identity provider. Alpine identifies /var/log/messages as an investigation source.
• SaaS / Cloud: Available host audit or console records and network-flow records for connections to the instance. Assess cloud-role or metadata-service access separately if host compromise is suspected.
• Network: Connections to the SSH service. Ordinary encrypted traffic does not reveal the password length.

Password-length analysis requires visibility at the authentication endpoint or into decrypted data. Encrypted packet size alone cannot establish use of this bypass.

9. Determining Attack Success

These are criteria for assessing an organization's own host, not claims of observed third-party compromise.

• Initial Access Confirmed: Evidence links password authentication for a login-permitted * account to a resulting session or shell.
• Follow-On Compromise Confirmed: Evidence links that session to root-level operations, unauthorized configuration changes, or other subsequent actions.
• Exposure Only: An affected configuration exists, but no successful login is established.
• Attempt Only: An authentication attempt is observed without evidence of successful access.

The public material describes research reproduction. Exploitation in real attacks was not confirmed in the inspected disclosures.

10. Investigation Playbook

• Trigger: Discovery of an affected musl/OpenSSH configuration or unexpected password acceptance for a * account.
• Initial Checks: Verify the OpenSSH package and patch status, C library, PAM path, effective password-authentication setting, account fields, suitable salt sources, and login restrictions.
• Host Investigation: Review available authentication records, process accounting, shell history, file changes, and doas or sudo records.
• Identity and Cloud Scope: Separate local-account compromise from cloud IAM compromise. Investigate instance-role or metadata-service use where relevant.
• Follow-On Investigation: Check for unauthorized keys, accounts, services, scheduled tasks, or credential access.
• Containment: Restrict SSH exposure and apply a fixed package. If immediate updating is not possible, disable password authentication. Validate the configuration, restart sshd, and confirm the effective setting.
• Credential Response: Remove unauthorized keys and rotate credentials shown or reasonably suspected to have been exposed.
• Classification: Report exposure, attempts, successful authentication, and root-level activity separately.

Before changing remote authentication settings, ensure that an approved alternative login or recovery path works.

11. Defense and Detection Ideas

These are defensive proposals based on the disclosed mechanism.

• Single-Event Detection: Alert on unexpected Accepted password events for accounts whose password field is *.
• Correlation: Link SSH authentication to privilege-elevation commands and subsequent system changes. Choose the time window according to the environment rather than treating a fixed interval as part of the exploit.
• Fleet Hunting: Identify musl-based systems that actually run OpenSSH without PAM and allow password authentication.
• Detection Limits: Standard authentication logs normally do not record the supplied password length, so a log entry alone may not distinguish this exploit from another authentication path.
• Priority Fix: Install OpenSSH 10.6p2 or the vendor's backport and restart sshd.
• Temporary Mitigation: Disable password authentication in the effective configuration and restrict exposure while preparing the update.

A ! field is not the same as *; it is not the error-string match described here. An unexpected login involving any disabled account may still warrant investigation, but it should not automatically be attributed to this vulnerability.

12. Facts / Inference / Hypothesis

Facts

• The bypass requires the relevant musl behavior, OpenSSH password checking without PAM, enabled password authentication, a login-permitted * account, and a suitable borrowed $5$ or $6$ salt.
• The relevant input range is 257–1024 bytes. OpenSSH rejects longer input before hashing rather than truncating it.
• This error-string match does not bypass the password of an account that has a valid password hash.
• OpenSSH 10.6p2 avoids the issue in its password-checking logic. Alpine also provides backported fixes and requires a restart of the running daemon after updating.
• The researcher described approximately 17,600 configuration and input tests. The inspected disclosures did not confirm exploitation in real attacks.

Inference

• Asset checks that assume glibc-based behavior may miss affected lightweight systems or appliances. Assessment must examine the actual authentication configuration, not the distribution name alone.

Hypothesis

No additional hypotheses. Unconfirmed matters are listed under "Open Questions and Further Investigation".

13. MITRE ATT&CK Mapping

14. Open Questions and Further Investigation

• Whether the condition was exploited before disclosure remains unknown.
• Default settings in vendor cloud images and appliances require individual verification.
• The presence of musl or an older OpenSSH version alone does not establish that every required condition is present.

15. Impact on SOCs and Organizations

Organizations running lightweight Linux systems should not assume that an account intended for SSH-key use cannot accept passwords. Review the C library, PAM path, effective SSH settings, account fields, and privilege-elevation configuration together.

SOC teams should investigate unexpected password acceptance for * accounts and any subsequent privileged activity. Administrators must include a daemon restart in the remediation procedure: replacing the package files alone leaves the old process running.

16. Summary by Role

• SOC: Correlate password acceptance for * accounts with suspicious sessions, privilege elevation, and system changes.
• Administrators: Install OpenSSH 10.6p2 or the vendor's backport and restart sshd. For temporary mitigation, validate and apply disabled password authentication, restart, and verify the effective configuration.
• Users: Follow the administrator's authentication guidance. Using an SSH key does not remove the need to update an affected server. 最新の応答

GPT-6.1 Sol
中
なし
最小
軽
中
高
極高
マックス
ウルトラ
パーシステント
出力
出力を作成
ソース
ウェブ検索
回答が完了しました