# OpenSSH on musl libc (Alpine Linux) authentication bypass via overly long password ("*sshole")

> OpenSSH prior to 10.6p2 on musl-based Linux systems built and run without PAM allows password login to accounts whose password field is an asterisk (such as root or key-only users) when the attacker supplies a password of 257-1024 characters. The flaw, dubbed *sshole and reported by Özgün Kültekin of Wakefield, is fixed in OpenSSH 10.6p2 (2026-11-05); no in-the-wild exploitation has been reported.

- **Published:** 2026-11-05T19:06:14Z
- **Last reviewed:** 2026-11-05T20:33:05.541Z
- **Canonical:** https://intel.threadlinqs.com/threat/TL-2026-5338
- **ID:** TL-2026-5338
- **Severity:** HIGH (CVSS 8.1)
- **Category:** VULNERABILITY
- **Status:** PATCHED
- **Detections:** 9 (1 shown free below) · **IOCs:** 28
- **CVEs:** CVE-2016-6210, CVE-2026-123158

## Description

*sshole is an authentication bypass arising from the chaining of three behaviors. First, musl libc's crypt() returns the string "*" instead of NULL when it cannot compute a hash (behavior dating to August 2012, musl commit b3c4cc12). Second, musl's SHA-512 crypt implementation caps passwords at 256 bytes (added 2012-08-29), so a longer password makes crypt() fail and return "*". Third, since the July 2016 fix for the OpenSSH user-enumeration timing attack (CVE-2016-6210), sshd hashes the supplied password for accounts with no usable hash using a salt borrowed from another account, and then compares the crypt() output against the stored password field. Accounts locked for password login conventionally carry an asterisk in that field (a convention dating to 1980).

When an attacker supplies a password between 257 and 1,024 characters, musl's crypt() fails and returns "*", which matches the "*" stored for the target account, so authentication succeeds without knowing any password. Accounts normally protected from password login, such as root, key-only deployment users, and LDAP-backed users, can therefore be logged into. Exploitation requires all of: a musl libc system (not glibc), sshd built or run without PAM (UsePAM no, the Alpine default), PasswordAuthentication enabled (the default), at least one other account with a valid password hash (the source of the borrowed salt), and a target account with an asterisk in its password field. Alpine Linux is the primary affected distribution, notably its official AWS and Azure cloud images with the default alpine user and its Docker images; other musl-based environments such as OpenWrt, Buildroot and Yocto-based embedded systems are also exposed. Alpine 3.16 (2022) changed the root password field from "!" to "*", which made root reachable. Debian, Ubuntu, Fedora and other glibc systems, PAM-enabled builds, OpenBSD and Dropbear are not affected.

The root cause lies in musl's crypt() behavior, but OpenSSH 10.6p2, released 2026-11-05, implements a workaround inside sshd; the release note says it avoids a password authentication bypass exploitable through sshd(8) that affects some Linux systems built and run with PAM support disabled. The issue was found via fuzzing after an OpenSSH security review on 2026-10-30 patched nearby code. Mitigation before patching is to set PasswordAuthentication no and restart sshd. The researcher site sshhole.com offers a check for whether a system was compromised, and recommends auditing access logs for unauthorized sessions. No CVE ID or CVSS score has been stated in the sources reviewed; severity is an analyst estimate. The Register reports no documented exploitation of vulnerable systems.

## MITRE ATT&CK

- T1190 Exploit Public-Facing Application
- T1133 External Remote Services
- T1078.003 Valid Accounts: Local Accounts
- T1078.003 Valid Accounts: Local Accounts
- T1078.003 Valid Accounts: Local Accounts
- T1078.003 Valid Accounts: Local Accounts
- T1021.004 Remote Services: SSH
- T1136.001 Create Account: Local Account
- T1098.004 Account Manipulation: SSH Authorized Keys

## Free detection (Splunk SPL, Microsoft KQL, Sigma)

***sshole OpenSSH musl Password Login to Locked/Key-Only Account — Exploitation (SPL)** (`TL-2026-5338-SPL-001`)

Detects successful sshd password authentication for accounts that should never accept a password (root, the default cloud user alpine, key-only deploy/admin users). On musl libc systems running OpenSSH older than 10.6p2 without PAM, a 257-1024 character password makes crypt() return * which matches the * in the locked account's password field (*sshole, TL-2026-5338, T1190/T1078.003). Behaviour-first: the over-long password is not logged, so the successful password login to a locked account is the observable.

- **Languages:** Splunk SPL, Microsoft KQL, Sigma
- **ATT&CK:** T1190, T1133, T1078.003, T1021.004
- **Data sources:** linux_secure, syslog, sshd authentication logs
- **Severity:** high
- **Confidence:** high

### Splunk SPL

````spl
index=linux (sourcetype=linux_secure OR sourcetype=syslog) earliest=-24h "sshd" "Accepted password for" ```*sshole TL-2026-5338: musl crypt() returns * for 257-1024 byte passwords, so sshd without PAM accepts password login for locked accounts``` | rex "Accepted password for (?<auth_user>\S+) from (?<src_ip>\S+) port (?<src_port>\d+)" | where in(auth_user,"root","alpine","admin","deploy","ubuntu","ec2-user") | eval src_scope=if(cidrmatch("10.0.0.0/8",src_ip) OR cidrmatch("172.16.0.0/12",src_ip) OR cidrmatch("192.168.0.0/16",src_ip),"internal","external") | stats count min(_time) as first_seen max(_time) as last_seen values(src_scope) as src_scope by host, auth_user, src_ip | convert ctime(first_seen) ctime(last_seen)
````

### Microsoft KQL

```kql
// *sshole TL-2026-5338: password login to locked/key-only accounts on musl sshd without PAM (T1190, T1078.003)
Syslog
| where TimeGenerated > ago(24h)
| where ProcessName =~ "sshd" and SyslogMessage startswith "Accepted password for"
| parse SyslogMessage with "Accepted password for " AuthUser " from " SrcIp " port " SrcPort " " *
| where AuthUser in~ ("root", "alpine", "admin", "deploy", "ubuntu", "ec2-user")
| extend SrcScope = iff(ipv4_is_private(SrcIp), "internal", "external")
| summarize Logins = count(), FirstSeen = min(TimeGenerated), LastSeen = max(TimeGenerated) by Computer, AuthUser, SrcIp, SrcScope
| order by LastSeen desc
```

### Sigma

```yaml
title: OpenSSH musl sshole Password Login to Privileged Account
id: 7c1b2f64-5d3a-4e8b-9a41-2f6c0d8e1a01
status: experimental
description: Detects successful sshd password authentication for root or key-only default accounts. On musl libc hosts running OpenSSH before 10.6p2 without PAM, an over-long password of 257 to 1024 characters bypasses authentication for accounts whose password field is an asterisk (sshole, TL-2026-5338).
references:
    - https://sshhole.com/
    - https://www.openssh.org/releasenotes.html#10.6p2
    - https://www.theregister.com/security/2026/11/05/get-root-on-a-musl-linux-system-by-slamming-it-with-an-overly-long-password/5307910
author: AII-Detector — ThreadLinqs Intelligence
date: 2026/11/05
tags:
    - attack.initial-access
    - attack.t1190
    - attack.t1133
    - attack.t1078.003
    - attack.lateral-movement
    - attack.t1021.004
logsource:
    product: linux
    service: sshd
detection:
    keywords:
        - 'Accepted password for root from'
        - 'Accepted password for alpine from'
        - 'Accepted password for admin from'
        - 'Accepted password for deploy from'
        - 'Accepted password for ubuntu from'
        - 'Accepted password for ec2-user from'
    condition: keywords
falsepositives:
    - Administrators legitimately using password login for root on hosts where root has a real password hash
    - Break-glass or console-recovery logins from a management network
level: high
```

**Known false positives:**

- Administrators legitimately using password login for root on hosts where root has a real password hash
- Break-glass or console-recovery logins from a management network

**Tuning notes:** Adjust the account list to the key-only or locked accounts in your estate. Restrict to hosts inventoried as musl (Alpine, OpenWrt, Buildroot, Yocto) running OpenSSH older than 10.6p2 without PAM. Exclude known bastion/management source ranges. Alpine logs to /var/log/messages, so confirm the sourcetype your forwarder assigns (syslog vs linux_secure). Remove the alert once PasswordAuthentication is disabled or openssh 10.6p2+ is deployed.

### 8 more detection rules (Splunk SPL, Microsoft KQL, Sigma), unlock with TL Creds

- *sshole [indicator] musl Password Login to Locked/Key-Only Account — Exploitation (KQL) (locked: unlock with TL Creds)
- *sshole Root Password Login Followed by Post-Exploitation Activity — Post-Exploitation (KQL) (locked: unlock with TL Creds)
- *sshole Source Sweeping Hosts With Privileged Password Logins or Failures — Lateral Movement (KQL) (locked: unlock with TL Creds)
- *sshole [indicator] musl Password Login to Locked/Key-Only Account — Exploitation (Sigma) (locked: unlock with TL Creds)
- *sshole Root Password Login Followed by Post-Exploitation Activity — Post-Exploitation (Sigma) (locked: unlock with TL Creds)
- *sshole Source Sweeping Hosts With Privileged Password Logins or Failures — Lateral Movement (Sigma) (locked: unlock with TL Creds)
- *sshole Root Password Login Followed by Post-Exploitation Activity — Post-Exploitation (SPL) (locked: unlock with TL Creds)
- *sshole Source Sweeping Hosts With Privileged Password Logins or Failures — Lateral Movement (SPL) (locked: unlock with TL Creds)

Sign up free to unlock the detection rules: https://threadlinqs.com/?modal=signup

## Sources

- [Get root on a musl Linux system by slamming it with an overly long password (The Register)](https://www.theregister.com/security/2026/11/05/get-root-on-a-musl-linux-system-by-slamming-it-with-an-overly-long-password/5307910)
- [*sshole - OpenSSH musl password authentication bypass (researcher site)](https://sshhole.com/)
- [OpenSSH Release Notes (10.6p2 and 10.6)](https://www.openssh.org/releasenotes.html)
- [OpenSSH 10.6p2 release notes entry](https://www.openssh.org/releasenotes.html#10.6p2)
- [CVE-2016-6210: OpenSSH user enumeration timing attack (origin of the borrowed-salt workaround)](https://nvd.nist.gov/vuln/detail/CVE-2016-6210)
- [sshhole.com compromise check](https://sshhole.com/#:~:text=did%20you%20get%20hacked%3F%20check.)
- [Alpine Linux security tracker](https://security.alpinelinux.org/)

## Full data

The other 8 detection rules (Splunk SPL / Microsoft KQL / Sigma) unlock with TL Creds; a free account includes daily creds: https://threadlinqs.com/?modal=signup
Indicator values unlock with TL Creds, at a lower price on Red and Purple; AI agents can query rules and IOCs through the Threadlinqs MCP server (Purple): https://intel.threadlinqs.com/mcp

Canonical: https://intel.threadlinqs.com/threat/TL-2026-5338