musl OpenSSH Auth Bypass: Alpine Linux SSHole Vulnerability

On 5 November 2026, security patches were released to address a zero-retry, single-packet authentication bypass vulnerability affecting specific non-PAM builds of OpenSSH. Dubbed SSHole by its discoverer, the alpine linux openssh vulnerability permits an unauthenticated remote attacker to gain interactive shell access without supplying a valid password, bypassing standard password authentication controls completely.

The flaw arises from an architectural collision between OpenSSH’s fallback credential evaluation logic and the implementation of standard C library cryptographic functions within musl libc. When targeting a service account or user account configured for public key or certificate authentication—indicated by an asterisk (*) in the /etc/shadow password field—sending a password payload longer than 256 characters alters the internal hashing outcome when a salt is borrowed from another active account on the system.

Because Alpine Linux relies on musl libc by default rather than glibc and forms the base operating system for over one billion Docker Hub image pulls, the exposure footprint spans cloud-native environments, edge gateways, industrial controllers, and network equipment. Platforms compiled against standard C libraries with PAM enabled remain unaffected.

Executive Summary: The SSHole Authentication Bypass

The SSHole vulnerability represents a class of logic and library interaction bugs where separate components function within their isolated design limits, yet produce a critical security failure when combined. The flaw had been latent in underlying software components for ten years prior to its public disclosure in November 2026.

Unlike conventional SSH password attacks that rely on dictionary matching, credential stuffing, or brute-force timing analysis, SSHole operates deterministically. An attacker transmitting a password payload exceeding 256 characters during a standard SSH user authentication request can instantly bypass password checks under specific target conditions. According to analysis published by Ars Technica, maintainers confirmed that the exploit succeeds on a single connection attempt, requires zero retries, and reliably yields shell access.

The vulnerability specifically targets OpenSSH servers compiled without PAM support and linked against musl libc. While root accounts configured with the standard OpenSSH setting PermitRootLogin prohibit-password prevent direct unauthenticated root access, any non-root account configured with an asterisk in /etc/shadow can be compromised. If that compromised user possesses administrative elevation privileges via sudo or doas, full host takeover follows immediately.

Architectural Breakdown: OpenSSH, musl libc, and PAM Dependencies

To understand why SSHole occurs, system architects must evaluate how OpenSSH abstracts user authentication across different C libraries and authentication frameworks. In traditional Linux distributions such as Ubuntu, Debian, Red Hat Enterprise Linux, or SUSE, OpenSSH is compiled with Pluggable Authentication Modules (PAM) support enabled.

When PAM is active, OpenSSH delegates the verification of user credentials to external system modules managed via libpam. The OpenSSH daemon (sshd) passes the submitted password string to PAM, which evaluates the input against /etc/shadow or remote directories (such as LDAP or Active Directory) using its own validation pipeline. Under this configuration, the C library’s native crypt(3) implementation is never called directly by sshd during password checks.

In minimal Linux distributions, container base images, and embedded environments, developers frequently disable PAM during the OpenSSH build process. Disabling PAM reduces binary overhead, removes system dependencies, and minimises memory usage. When compiled without PAM, OpenSSH falls back to its native internal password verification logic, which interacts directly with the system’s standard C library by calling the crypt(3) function.

# Standard glibc dynamic linking check on standard Linux systems
$ ldd /usr/sbin/sshd
        linux-vdso.so.1 (0x00007ffc12345000)
        libpam.so.0 => /lib/x86_64-linux-gnu/libpam.so.0 (0x00007f8123400000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f8123200000)

# Non-PAM musl dynamic linking check on minimal systems
$ ldd /usr/sbin/sshd
        /lib/ld-musl-x86_64.so.1 (0x00007f9988000000)
        libc.musl-x86_64.so.1 => /lib/ld-musl-x86_64.so.1 (0x00007f9988000000)
        # Note: No libpam.so linkage present

GNU C Library (glibc) and musl libc handle string parsing, memory allocation, and hashing limits differently inside crypt(3). For over a decade, non-PAM OpenSSH builds running on musl libc contained an unrecognised edge-case mismatch in how long password buffers were handled when performing dummy salt comparisons for disabled accounts.

Dissecting the Flaw: Password Salts and Long String Invalidation

The internal mechanism of SSHole relies on how OpenSSH mitigates timing attacks when checking accounts that do not possess a standard password. In Linux systems, /etc/shadow stores user account authentication metadata. Each line contains fields separated by colons:

username:password_hash:lastchanged:minimum:maximum:warn:inactivity:expiration:flag

When an account is intentionally configured for key-only, certificate-only, or disabled password access, the password field is set to an asterisk (*) or an exclamation mark (!). Because an asterisk does not match any valid output hash format, standard password verification calls should always fail.

# Example /etc/shadow contents
root:$6$vE8k...$9x12...:19600:0:99999:7:::
deploy:*:19600:0:99999:7:::
appuser:*:19600:0:99999:7:::

To prevent timing attacks—where a remote attacker measures response delays to determine whether a username exists or whether an account has a valid hash—OpenSSH executes a fake crypt() computation when encountering a non-hash value like *. To run this fake computation, OpenSSH requires a valid salt structure. It searches /etc/shadow for another active user account that contains a valid SHA256 (prefixed by $5$) or SHA512 (prefixed by $6$) hash and borrows that account’s salt.

Security researchers at Check Point confirmed that without at least one active SHA256 or SHA512 hashed account on the target system, sshd cannot borrow a valid salt, causing the attack logic to fail. Systems containing only accounts with disabled hashes or legacy MD5/DES hashes are not susceptible to this specific borrowing path.

+-----------------------------------------------------------------------------------+
|                           SSHole Execution Sequence                               |
+-----------------------------------------------------------------------------------+
| 1. Attacker sends SSH_MSG_USERAUTH_REQUEST for account 'deploy' (shadow password '*')|
| 2. sshd detects '*' in /etc/shadow for 'deploy'                                  |
| 3. sshd locates valid SHA512 ($6$) salt from 'root' account to execute fake crypt()|
| 4. Attacker provides password string > 256 characters                             |
| 5. musl libc crypt() processes >256 byte buffer with borrowed SHA512 salt         |
| 6. musl crypt() evaluation returns truncation/error condition matching sshd expectation|
| 7. sshd evaluates returned structure as positive match -> AUTHENTICATION SUCCESS  |
+-----------------------------------------------------------------------------------+

When the attacker submits a password payload longer than 256 characters, the input string exceeds the internal buffer processing boundary inside musl libc’s crypt() implementation under SHA256/SHA512 salt parameters. Instead of returning an explicit failure or safely aborting the hash comparison, musl’s internal handling generates a string output condition that OpenSSH’s non-PAM authentication check interprets as a successful password match. Consequently, sshd grants interactive shell access to the requesting client.

Exploitation Prerequisites and Threat Vector Analysis

Exploiting SSHole does not require complex heap grooming, memory corruption spraying, or race conditions. However, the target environment must satisfy four specific technical criteria simultaneously:

1. OpenSSH Non-PAM Build: The OpenSSH daemon must be compiled without PAM support and linked against musl libc.
2. Passwordless Target Account: The account being logged into must have an asterisk (*) in its /etc/shadow password field.
3. Active SHA256/SHA512 Host Account: The target operating system must contain at least one other active account configured with a valid $5$ (SHA256) or $6$ (SHA512) password hash for salt borrowing.
4. Oversized Password Payload: The client authentication request must transmit a password string containing more than 256 characters.

From a threat vector perspective, an exposed SSH port (port 22) on any public or internal network segment allows immediate testing. Because the exploit vector requires only standard SSH protocol messages containing a large string payload, network intrusion detection systems (NIDS) that do not inspect encrypted SSH payload content or track pre-authentication packet sizes will fail to detect the attempt prior to session establishment.

Blast Radius: Containers, Routers, and Infrastructure Footprint

The operational impact of SSHole is shaped by the widespread adoption of Alpine Linux across cloud-native environments and embedded firmware systems. Alpine’s minimal resource footprint (typically under 6 MB for a base container image) makes it the default choice for platform engineers and software vendors.

The official Alpine Linux Docker Hub image has recorded over one billion pulls. In microservice architectures, Alpine base images are frequently modified to include openssh-server for remote debugging, operational maintenance, or automated file transfers via SFTP. Container builds that create deployment users with useradd -p '*' or passwd -u inadvertently construct the exact prerequisites required for SSHole.

According to telemetric data from Detectify, Shodan indexes approximately 22 million Internet-accessible systems exposing SSH on port 22. While only a specific subsegment of these hosts meets all four prerequisite conditions, the automated nature of the attack allows threat actors to perform internet-wide scanning sweeps with minimal overhead.

Edge devices—including industrial control systems, smart TVs, consumer routers, and remote IoT gateways—present severe remediation challenges. Many edge devices execute static firmware images lacking package managers, dynamic patch delivery systems, or field-upgradable bootloaders. Devices running custom musl/OpenSSH stacks without PAM will remain vulnerable indefinitely unless firmware updates are built and flashed manually.

Maintainer Conflict: OpenSSH vs musl Root Cause Debates

The disclosure of SSHole sparked an architectural debate regarding software boundaries and bug attribution between upstream library maintainers and application developers.

OpenSSH maintainers took the position that the fundamental flaw exists within musl libc’s crypt(3) handling when processing long input strings against SHA256/SHA512 salts. However, acknowledging the practical security impact on production systems, OpenSSH developers implemented avoidance logic directly within sshd. The patch adds explicit sanitisation and input length validation before passing credential strings to the underlying library routines.

“We consider the root cause of this bug to be outside sshd, but it is exploitable via sshd and can be avoided there.”

— OpenSSH Maintainers Security Advisory Statement

Conversely, musl libc lead developer Rich Felker argued that musl is not inherently buggy, asserting that the library operates within its design specification and that the vulnerability stems from improper usage patterns by the calling application. Felker noted that passing invalid password structures and relying on undefined string comparison returns for authorization decisions misuses standard library interfaces.

“It is my position that this is not a bug in musl just an erroneous use by the caller.”

— Rich Felker, musl libc Lead Maintainer

Despite this disagreement on root cause attribution, Felker indicated that musl maintainers plan structural updates to salt validation and internal buffer management in upcoming library releases to prevent similar misapplications. This interaction highlights a persistent challenge in software engineering: when upstream library contracts leave edge-case behaviors implicit, downstream applications risk introducing critical security vulnerabilities during error handling.

Practical Mitigation, Detection, and Audit Playbook

Platform engineers, SREs, and system administrators must audit their fleets immediately to identify vulnerable Alpine Linux instances, edge deployments, and container base images.

1. Auditing System Prerequisites

To determine if a system is susceptible, run diagnostic checks against /etc/shadow and the sshd binary. Execute these audit commands in a safe environment.

# Audit Command 1: Search for accounts configured with asterisk (*) password fields
$ awk -F: '$2 == "*" {print $1}' /etc/shadow
deploy
appuser

# Audit Command 2: Check for presence of SHA256 ($5$) or SHA512 ($6$) hashes
$ grep -E '^\w+:\$(5|6)\$' /etc/shadow
root:$6$vE8k9X1z$8N...:19600:0:99999:7:::

# Audit Command 3: Verify if OpenSSH is linked against musl without PAM
$ scanelf -n /usr/sbin/sshd | grep -E 'musl|pam'
# If output shows libmusl and lacks libpam, the binary uses native C library crypt

If Audit Command 1 returns user accounts, Audit Command 2 returns at least one active hash, and Audit Command 3 confirms a musl non-PAM build, the host is vulnerable.

2. Patching Alpine Linux and Container Images

Alpine Linux released updated OpenSSH packages on 5 November 2026. Upgrade standard hosts using apk:

# Update package indices and upgrade OpenSSH package (test in staging prior to production deployment)
$ sudo apk update
$ sudo apk upgrade openssh-server openssh-client

# Restart the SSH daemon service
$ sudo rc-service sshd restart

For containerised infrastructure, update your Dockerfile definitions to force a fresh package retrieval during container image builds:

# Standard Alpine Dockerfile update
FROM alpine:3.20

# Force package index update and fetch patched OpenSSH package
RUN apk add --no-cache openssh-server>=9.9_p1-r0

EXPOSE 22
CMD ["/usr/sbin/sshd", "-D"]

3. OpenSSH Configuration Hardening Workaround

If package upgrades cannot be applied immediately (such as in immutable embedded devices), disable password authentication globally within /etc/ssh/sshd_config. Disabling password authentication bypasses the vulnerable crypt() code path entirely.

# Apply configuration hardening in /etc/ssh/sshd_config
PasswordAuthentication no
KbdInteractiveAuthentication no
ChallengeResponseAuthentication no

# Reload sshd configuration
$ sudo kill -HUP $(cat /var/run/sshd.pid)

Key Takeaways and Long-Term Defensive Engineering

The SSHole vulnerability provides critical engineering lessons for platform teams constructing minimal software stacks:

• C Library Choice Dictates Security Boundaries: Choosing musl libc for size optimization changes runtime behavior compared to glibc. Security architectures must account for non-PAM library interactions when using lightweight base distributions.
• Eliminate Unnecessary SSH Daemons in Containers: Remote administration of containers should occur via container orchestrator APIs (such as kubectl exec or docker exec) rather than running standalone SSH daemons inside container images.
• Audit Account Configurations in Shadow Files: System provisioning scripts must avoid leaving orphan user accounts with * entries when password authentication is exposed to untrusted networks.
• Enforce Supply Chain Visibility: Dependency scanners must inspect low-level system binaries and standard C library combinations, not just high-level application packages.

Frequently asked questions

What specific conditions make an Alpine Linux server vulnerable to SSHole?

An Alpine Linux server is vulnerable if it runs OpenSSH compiled against musl libc without PAM support, contains at least one target account with an asterisk (*) in /etc/shadow, has at least one other active account with a SHA256 ($5$) or SHA512 ($6$) hash, and accepts SSH connections on an exposed network port.

Are root accounts directly accessible using this password bypass technique?

Root accounts are not directly accessible if OpenSSH retains its default PermitRootLogin prohibit-password configuration. However, if an attacker uses SSHole to compromise a non-root service account that possesses passwordless sudo or doas privileges, they can achieve complete host root escalation immediately after logging in.

Why does the SSHole exploit require another account on the system to have a SHA256 or SHA512 password hash?

When processing passwordless accounts containing an asterisk (*), OpenSSH attempts to prevent timing attacks by borrowing a salt from a valid host account to run a fake hash computation. The specific buffer truncation flaw in musl libc’s crypt(3) function requires a SHA256 or SHA512 salt structure to trigger the invalid match logic.

Does SSHole affect standard glibc-based distributions like Ubuntu, Debian, or RHEL?

No. Standard distributions like Ubuntu, Debian, and Red Hat Enterprise Linux use glibc and compile OpenSSH with Pluggable Authentication Modules (PAM) support enabled. In PAM-enabled builds, credential validation is handled by libpam modules rather than direct calls to musl’s C library crypt(3) function.

Is OpenWrt vulnerable by default to the SSHole exploit?

OpenWrt is not vulnerable by default because it uses Dropbear as its default SSH implementation rather than OpenSSH. OpenWrt systems are only potentially exposed if an administrator manually replaces Dropbear with an unpatched OpenSSH package compiled against musl libc without PAM support.