As of late November 5, 2026, a critical vulnerability dubbed “*sshole” has emerged, allowing unauthorized remote access to Linux devices via OpenSSH. The flaw specifically targets Alpine Linux and similar distributions using the musl libc library without Pluggable Authentication Modules (PAM), enabling passwordless root-level login through a single connection attempt.
The Mechanics of the Alpine Linux Vulnerability
The exploit centers on a specific architectural intersection: the OpenSSH server implementation interacting with the musl library. Unlike standard glibc-based distributions, Alpine Linux relies on musl, a lightweight, minimalist C library. When OpenSSH is compiled against musl and configured without PAM, the authentication handshake process fails to correctly validate password-protected accounts.
For an attacker to gain access, the target system must meet two rigid criteria. First, the system must contain at least one user account utilizing SHA256 or SHA512 password hashing. Second, the account must be explicitly configured as passwordless, denoted by a “*” in the password field within the /etc/shadow file. This configuration is standard for accounts relying exclusively on certificate-based authentication, making the vulnerability particularly dangerous for automated CI/CD pipelines and headless IoT devices.
Why Passwordless Accounts Become Open Doors
The vulnerability essentially bypasses the authentication gate. Because the system is configured to expect no password for these specific accounts, the interaction between OpenSSH and musl misinterprets the request, granting access without requiring the expected certificate or credentials. Ars Technica reported that the exploit requires no retries and works on the first attempt, significantly lowering the barrier for automated botnets scanning the public internet for vulnerable nodes.
Because Alpine is the default choice for many containerized environments, the footprint of potentially affected systems is massive.
The Broader Impact on Containerized Infrastructure
While smaller images reduce the attack surface by excluding unnecessary binaries, the use of alternative libraries like musl can introduce edge cases that standard security auditing tools may overlook.
A ten-year-old security flaw enables unauthorized individuals to access systems running certain Alpine Linux setups, and potentially other distributions, without needing a password. The issue stems from how OpenSSH, the software library that handles SSH connections, communicates with musl, which is a lightweight alternative to the standard libc library utilized by Alpine unlike most other Linux environments. Furthermore, for this to occur, the OpenSSH installation using musl (pronounced muscle) must be configured without PAM (pluggable authentication modules), which is the system responsible for managing user login and access verification.
As developers push for faster deployment times and lower cloud storage costs, the use of musl-based Alpine images has become nearly ubiquitous.
Audit Password Files and Configure PAM to Prevent Bypass
System administrators should immediately audit their /etc/shadow files for accounts containing a “*” in the password field. If those accounts are not strictly intended for certificate-only access, they should be disabled or protected with a strong, salted password. Additionally, ensuring that OpenSSH is configured with PAM enabled—where possible—provides a necessary defense-in-depth layer that prevents this specific bypass.
For those managing large fleets of Alpine-based containers, the priority is verifying the build configurations of the underlying base images. If a container does not strictly require SSH access, the service should be removed entirely to eliminate the attack vector.
| Component | Requirement for Exploitation |
|---|---|
| Library | musl (must be used instead of glibc) |
| Authentication | PAM must be disabled |
| User Config | “*” in /etc/shadow password field |
| Hash Type | SHA256 or SHA512 |
