🔍 Read the full analysis: A Closer Look At SSHole, OpenSSH’s Overlong-Password Bug on ThorstenMeyerAI.com
Prime made for students and young adults
- Fast, free delivery for dorm and study essentials
- Prime Video and Amazon Music included
- Member-only deals
TL;DR
SSHole, tracked as CVE-2026-123158, can allow passwordless SSH access under a narrow set of Linux configurations using musl. OpenSSH released version 10.6p2 on Nov. 5, 2026, and public exploit code followed about four hours later, according to GreyNoise and BleepingComputer. Administrators should update and restart sshd or disable password authentication while they assess exposure.
OpenSSH 10.6p2 fixes a password-checking flaw, tracked as CVE-2026-123158 and nicknamed “SSHole,” that can let an attacker log in without a valid password on some Linux systems using the musl C library. The exposure depends on several conditions, including password authentication being enabled and OpenSSH running without PAM; Alpine Linux’s standard server package is a prominent example. Reports say exploit code appeared within hours of the fix, making prompt patching relevant for administrators of potentially affected systems.
The issue arises when sshd checks a password without PAM and calls the C library’s crypt() function. Alpine Linux’s advisory says musl returns an asterisk (*) as an error indicator when an input password is longer than 256 bytes. Some accounts that are not meant to authenticate with a password have that same character in the stored password field. Under the vulnerable conditions, the failed password check can appear to match the account’s stored value.
Alpine says the attacker must send a password between 257 and 1,024 bytes. It also lists a further condition: the machine must have at least one local account with a $5$ or $6$ password hash, which sshd uses as a salt for the check. The bypass concerns accounts whose password field is an asterisk; Alpine says accounts marked with an exclamation point are not affected in the same way.
OpenSSH released the fix in version 10.6p2 on Nov. 5. GreyNoise and BleepingComputer reported that public exploit code surfaced about four hours after the release, and GreyNoise observed a first successful break-in on one of its sensors about 40 hours after release. CISA added the vulnerability to its list of exploited vulnerabilities on Nov. 9. These reports do not establish that every system matching the broad description was targeted or compromised.
SSHole: OpenSSH’s overlong-password bug
A flaw can allow passwordless SSH access on some musl-based Linux systems when specific software and account settings coincide. Administrators should check exposure, patch, and restart sshd.
How the bypass can happen
The flaw depends on a combination of library behavior and SSH configuration.
The system uses musl, password authentication is enabled, and sshd checks passwords without PAM.
For an overlong password, musl crypt() returns an asterisk, which can match an account field marked with an asterisk.
Under the vulnerable conditions, the failed password check can appear to match the account’s stored value.
Check the full exposure
OpenSSH alone does not establish that a system is vulnerable; local build and account details matter.
Review SSH settings
Check whether the system uses musl, whether PAM is used for password checks, and whether password authentication is enabled.
Inspect local accounts
Alpine lists a further condition: at least one local account must have a $5$ or $6$ password hash.
Include embedded systems
Medcrypt reported reproducing the issue on a stock Yocto image; the supplied material gives no complete device inventory.
What reports establish
Exploit code and an observed intrusion followed the fix quickly, but the scope remains uncertain.
Patch and verify
Operators of potentially affected systems should act and then check for suspicious access.
- Install a fixed OpenSSH package and restart sshd; upgrading alone may leave the running daemon unchanged.
- If an update is not immediately possible, temporarily set PasswordAuthentication no.
- Review SSH logs for password logins to accounts with no password and investigate unexplained activity.
- Check distribution or device-vendor guidance, especially for embedded deployments.
Exposure Depends on Several SSH Settings
The flaw matters because it can turn an SSH service reachable over a network into an entry point without requiring a correct password, but only when the relevant software and account conditions coincide. For administrators, that makes identifying the system’s libc, PAM configuration, and password-authentication settings more useful than assuming all OpenSSH installations are exposed.
The practical risk can extend beyond the account initially reached. Alpine warns that a user able to become root through a separate mechanism, such as passwordless doas, may provide a path to elevated access. Its advisory identifies official tiny-cloud images from versions 3.18.11 through 3.24.3 as a concern once a qualifying $6$ hash exists on the machine. Administrators should check both SSH access and account privileges.
Public exploit code and a reported sensor intrusion shortly after the patch increase the urgency for exposed operators. They do not, by themselves, show how widespread exploitation is. The confirmed scope in the supplied advisories is narrow, and major distributions have said their own builds are not affected.
Popular right now
LG 77-Inch OLED evo C6 4K Smart TV
Breville Barista Touch Impress Espresso Machine, Noir (BES881NRE)
Bose QuietComfort True Wireless Earbuds with Active Noise Cancellation, Bluetooth 5.3, USB-C Charging, IPX4, Black
As an affiliate, we earn on qualifying purchases.
Why the musl Error Matches an Account
On systems that use password hashes, a field containing * can mark an account that should not accept password logins. In the affected path, however, an overlong password causes musl’s crypt() to return the same character as an error signal. The flaw results from the interaction between that return value and sshd’s handling of it, rather than from a password that matches a valid hash.
The parties describe responsibility differently. OpenSSH says the root cause is outside sshd, though it is exploitable through sshd and can be avoided there. Musl maintainer Rich Felker has argued that musl is not at fault and characterized the issue as erroneous use by the caller; he said musl may change the mechanism in an upcoming release cycle.
The advisories say systems using glibc, PAM-based password checks, or password authentication disabled are not affected by this issue. Ubuntu says its OpenSSH is linked against glibc and uses PAM; Red Hat says its products are not affected. Debian’s tracker rates the issue “unimportant” for its packages and lists upstream fix 1:10.6p2-1 in its unstable branch. Alpine’s advisory lists fixed packages across its branches, including older releases.
“musl’s crypt() returns the string * as an error indicator when the key is over 256 bytes long. * is also exactly what the stored field contains for every account with no password, so the ‘hash’ matches and the login succeeds.”
— Alpine Linux advisory
Which Devices Still Need Checking
The exact number of exposed and compromised systems is not established in the supplied material. GreyNoise’s reported successful break-in was observed on one sensor; it does not quantify attacks across the internet. The conditions are also dependent on local build choices and configuration, so the presence of OpenSSH alone does not show that a host is vulnerable.
Embedded deployments need particular attention. The security firm Medcrypt reported on the oss-security mailing list on Nov. 9 that it reproduced the issue on a stock Yocto image without unusual configuration. The supplied material does not give a complete inventory of affected Yocto, OpenWrt, or Buildroot products, nor does it identify which vendors have shipped fixes.
The disagreement over whether the root cause belongs to sshd or musl remains unresolved in these statements. That debate does not change the immediate mitigation: OpenSSH 10.6p2 includes the fix, and affected administrators can also turn off password authentication. The full extent of exploitation and any impact to specific organizations have not been established here.
Patch, Restart, Then Review Logs
Administrators should identify whether their systems use Linux with musl, whether sshd checks passwords without PAM, and whether password authentication is enabled. If the conditions may apply, install a fixed OpenSSH package and restart sshd; Alpine cautions that upgrading the package alone does not replace a daemon that is already running.
If an immediate update is not possible, set PasswordAuthentication no as a temporary mitigation. Operators should then review SSH logs for password logins to accounts that have no password and investigate any activity that cannot be explained. Alpine provides fixed packages for its listed branches, while administrators of embedded or vendor-managed systems should check for guidance from their supplier.
Further clarity will depend on distribution and device-vendor advisories, musl’s planned handling of the error return, and continued reporting on exploitation. No additional milestone or complete affected-device list is specified in the source material.
Key Questions
What is SSHole?
SSHole is the nickname for CVE-2026-123158, a flaw in password checking that can affect some OpenSSH installations on Linux systems using musl. It can allow access to certain accounts without a valid password when several software and configuration conditions are met.
Does the bug affect every OpenSSH server?
No. The advisories describe a narrow set of conditions: Linux with musl, password checks performed without PAM, password authentication enabled, an account with an asterisk in its password field, and at least one local account with a qualifying $5$ or $6$ hash. The supplied advisories say glibc-based systems and PAM-based checks are not affected.
How can administrators reduce the risk?
Install a fixed version, including OpenSSH 10.6p2 where applicable, and restart sshd. If a patch cannot be applied promptly, disable password logins by setting PasswordAuthentication no, then check logs for suspicious password access to accounts that should not accept passwords.
Has the flaw been exploited?
GreyNoise reported a successful break-in on one of its sensors about 40 hours after the Nov. 5 release. CISA added the vulnerability to its exploited-vulnerabilities list on Nov. 9. The supplied information does not establish the total number of attacks or compromised systems.
Source: ThorstenMeyerAI.com
