Security researchers have uncovered *sshole, a decade-old vulnerability that can let attackers log into some Linux devices over SSH without knowing a password. The flaw affects certain Alpine Linux configurations and may extend to other systems that combine OpenSSH with musl, the lightweight C library used by Alpine instead of the more common libc implementations.
How *sshole works
The issue appears when several specific conditions line up. According to the source report, the target system must use OpenSSH with musl, must not use PAM for authentication, and must have at least one account protected by a password hashed with SHA256 or SHA512. The account being targeted also has to be configured as passwordless, using a “*” in the password field in /etc/shadow.
That passwordless setup is not unusual for accounts that rely on certificate-based authentication, which helps explain why the flaw may affect real-world systems rather than only edge cases. When the conditions are met, Alpine maintainers said an attacker who can reach the SSH port can log in without any password at all.
“An attacker who can reach your SSH port can log in without knowing any password,” Alpine maintainers said Thursday. “It takes one connection, works every time, and needs no retries.”
Why the attack succeeds
Security firm Check Point said the SHA256 or SHA512 requirement matters because sshd “borrows that account’s salt.” Without that element, the attack fails. The company also said its testing showed the targeted account must be active, not just contain a hash.
Researchers further reported that root accounts are protected under the default PermitRootLogin prohibit password setting. Even so, accounts with doas or sudo rights could still be used to gain root access after login.
Why Alpine Linux is in the spotlight
Although the prerequisites narrow the pool of vulnerable systems, *sshole still raises serious concerns because Alpine is widely used. The Docker Hub base image for Alpine has more than 1 billion downloads, and the distribution has long been popular in routers, smart TVs, industrial controllers, and other embedded devices that may be difficult or impossible to patch quickly.
Alpine has also become more common in desktops, servers, and container images. That broader adoption increases the chance that the bug has made its way into environments where SSH exposure is routine and patching discipline varies.
- Alpine Linux is widely used in embedded and container environments.
- Devices may be hard to update, especially in industrial and consumer hardware.
- Even a small percentage of vulnerable systems could represent a large number of reachable hosts.
OpenSSH, musl, and the disputed root cause
The precise source of the bug remains unsettled. OpenSSH issued an update Thursday and said, “We consider the root cause of this bug to be outside sshd, but it is exploitable via sshd and can be avoided there.”
Musl developer Rich Felker took a similar position from the library side, writing: “It is my position that this is not a bug in musl just an erroneous use by the caller.” Felker added that musl developers had wanted to change the relevant mechanism “for a while now” and planned to do so in an upcoming release.
Alpine has also released an update. The source material says there is no known CVE designation for the vulnerability at this time.
Potentially affected systems beyond Alpine
The discoverer of *sshole said OpenWRT is affected, though that platform normally uses Dropbear rather than OpenSSH for SSH connections. Maintainers do provide instructions for installing OpenSSH, which could create exposure in some deployments.
The same researcher also named buildroot and Yocto as affected, but that has not yet been confirmed. As a result, the safest assumption is broader caution: any Linux system that combines musl and OpenSSH should be reviewed carefully.
Security firm Detectify noted that Shodan lists around 22 million systems with SSH open on port 22. Only a fraction would satisfy the exact conditions for exploitation, but the attack is simple enough that scanning for susceptible hosts should not be difficult.
What administrators should do now
Administrators are being urged to investigate immediately if they run a Linux system that uses both musl and OpenSSH. The first step is to determine whether the machine uses the vulnerable combination and whether any accounts meet the password and configuration requirements described above.
From there, patching is the priority. Alpine and OpenSSH patches should be installed on all affected systems, and organizations with embedded or containerized Alpine deployments should pay special attention to base images and device firmware that may be harder to refresh.
Because the flaw can be triggered with a single successful connection and no retries, exposed SSH services should be treated as urgent. Systems with reachable accounts that have administrative rights deserve particular scrutiny.
For now, *sshole is a reminder that small implementation details can have outsized consequences when authentication layers interact in unexpected ways. Even without a CVE label, the combination of public SSH exposure, widespread Alpine use, and the ease of exploitation makes this a vulnerability worth addressing quickly.
Source: Original report
Was this helpful?
Explore more: Application Audit & Review More Cybersecurity Tech News
Last Modified: November 6, 2026 at 10:31 pm
0 views
