A recently disclosed vulnerability in OpenSSH allows attackers to log in to vulnerable systems without a password under certain circumstances. Primarily affected are lightweight Linux systems such as Alpine Linux, which are frequently used in Docker containers and embedded devices.
What exactly happened, and who is affected?
On November 5, 2026, a vulnerability in OpenSSH was publicly disclosed. It affects, among others, systems designed to operate in resource-constrained environments. These include systems based on Alpine Linux, as well as distributions such as OpenWRT (which runs on routers, among other devices) or Yocto. What these systems have in common is that OpenSSH is installed for "musl libc". With a CVSS score of 8.1 out of a possible 10, this is a serious vulnerability. It has been assigned the identifier CVE-2026-123158 and is known as *sshole.
What is musl libc?
Put simply, it is an extremely lightweight implementation of the C standard library. It offers fewer features than the "heavier", more memory-intensive glibc library. It enables developers to build space-efficient applications for highly specific purposes that do not require the full functionality of a C environment. This is particularly important for devices with limited memory and processing resources.
How does the vulnerability work?
The vulnerability in question has actually existed since 2016, but only in the combination of "OpenSSH + musl libc". Linux stores users' password hashes in a file (/etc/shadow). Certain accounts, such as the administrator account (known as "root" in Linux), should not be allowed to log in via SSH using a password in the first place. These are marked with an asterisk (*).
All other user accounts that are permitted to log in have a long string of characters following their username. This consists of an encoded specification of which hashing algorithm to use (SHA-256 or SHA-512 on the affected systems), followed by a cryptographic "salt" and the actual password hash. When a user enters their password, the entered password is hashed according to the specifications in /etc/shadow. If the result matches the entry in the file, the system assumes that the user has entered the correct password and grants access.
The problem is that a musl system function called crypt() produces an error when a password between 257 and 1024 characters long is entered. This error is also returned to OpenSSH in the form of an asterisk. OpenSSH, in turn, mistakenly interprets the single "*" as a hash rather than an error and compares it with the entry in /etc/shadow. It then determines that the hashes match and grants access. This is not what should happen; the login attempt should actually be rejected.
So, anyone who enters the letter "a" 257 times as their password when logging in via SSH suddenly gains access via SSH, with the privileges of an account that should not be allowed to log in at all – potentially even with administrator privileges in the worst-case scenario.
- However, it is not quite that simple. For this attack to succeed, a number of conditions must be met:
Linux with musl libc (Alpine Linux, OpenWRT and others)
OpenSSH without PAM (Pluggable Authentication Modules)
Password authentication is enabled
At least one user account with a valid SHA-256 or SHA-512 hash and another account that has only "*"
ALL of these conditions must be met for the vulnerability to be successfully exploited. This is the case, for example, with the default configuration of Alpine Linux, provided passwords have been set. Furthermore, multiple attempts are required.
Who is NOT affected?
In short: All glibc-based Linux distributions (e.g. Debian and its derivatives such as Ubuntu, Linux Mint and others), all non-Linux systems (BSD, Unix, Windows), and Linux systems where passwords are verified through PAM.
What Linux users should do now
Check whether routers, NAS devices or smart home devices have SSH access enabled.
Update the relevant firmware.
Administrator or SSH access to devices and systems should never be accessible from the internet. Check your router for any port forwarding rules that might expose these services.
Anyone who has installed an OpenSSH server on an OpenWRT router should take the measures outlined below. The preinstalled SSH server, "Dropbear", is not affected.
Immediate measures for administrators
Install the patch. The current version in which the vulnerability has been fixed is 10.6p2, or the latest package provided by the respective distribution. Note: On Alpine, packages from the "stable" branch retain their original OpenSSH version number, e.g. 10.3_p1-r2, but are nevertheless patched. What matters here is that the package is up to date.
Restart the service after installation. This ensures that the updated version of the daemon is actually running, rather than the old version.
If installing the latest package is not currently possible:
Set the options "PasswordAuthentication no" and "KbdInteractiveAuthentication no" in the sshd configuration file and restart the service here as well. Important: Make sure that key-based login works beforehand – otherwise, you may lock yourself out of the system!
Wherever possible, allow SSH logins using keys only.
Anyone using Docker images containing affected versions of the OpenSSH server should rebuild and redeploy the respective base images.
Carefully examine /var/log/messages; use grep to filter for sshd login entries involving accounts that are not authorized to log in. The search term here is "Accepted password".
Check whether new users have been created and whether there are new entries in authorized_keys.
If a compromise cannot be ruled out, the machine must be considered compromised. In this case, the system should be rebuilt from scratch and all secrets changed.
How the vulnerability was discovered
The discoverer of this vulnerability, Özgün Kültekin, used several AI agents, among other tools, to carry out a total of 17,600 different login attempts against differently compiled versions of SSH. This is a common and well-established technique known as "fuzzing", in which different inputs are fed into software to provoke responses that may provide clues about potential vulnerabilities.
And in one case, according to Kültekin, one of the tested OpenSSH instances "said yes to things it shouldn't".
Outlook
The time between the disclosure of a vulnerability and its active exploitation by various threat actors is becoming increasingly short. In this example, it took only around nine hours. Installing updates and patches is therefore something that needs to happen immediately, rather than being put off for another few weeks or months. And anyone who cannot install an update right now should definitely implement the hardening measures described above to prevent unauthorized access.
It is also worth taking another close look at your inventory: Where are vulnerable systems located? And are they accessible via SSH from the internet?
After all, a system that cannot be reached from the internet cannot be attacked via the internet.
