Imagine configuring a Linux account so nobody can log in with a password. An attacker connects over SSH, enters a ridiculously long password, and gets access anyway.
Any password. As long as it's long enough.
That's the problem behind CVE-2026-123158, nicknamed SSHole. The vulnerability allows attackers to bypass password authentication on certain Linux systems running OpenSSH, including affected Alpine Linux configurations.
It's a particularly strange bug because the server doesn't fail to check the password. It actually checks it, gets an error, and mistakes that error for a match.
What Is CVE-2026-123158?
Disclosed on 5 November 2026, CVE-2026-123158 is a high-severity authentication bypass affecting OpenSSH on Linux systems using the musl C library without Pluggable Authentication Modules (PAM).
Security researcher Özgün Kültekin of Wakefield discovered the flaw, which received a CVSS 3.1 score of 8.1 (High).
The flaw affects systems where OpenSSH handles password authentication without PAM and relies on musl's password-hashing implementation.
Alpine Linux is a notable example because its standard openssh-server package is built without PAM.
However, this vulnerability doesn't affect every OpenSSH installation. Several conditions must be present for exploitation to succeed.
The Password Check That Went Very Wrong
To understand SSHole, we need to look at how Linux handles passwords.
When you set a password for a Linux account, the system typically stores a hash rather than the password itself.
During authentication, the server hashes the password supplied by the user and compares the result with the stored value.
If they match, authentication succeeds. But what happens when an account isn't supposed to accept password authentication?
On some Linux systems, the password field in /etc/shadow contains an asterisk (*).
That character isn't a valid password hash. It's used to prevent password-based logins while potentially allowing other authentication methods, such as SSH keys.
In normal circumstances, no password should match it.
When an Error Looks Like the Correct Password
The vulnerability involves the interaction between OpenSSH and musl's crypt() function, which is responsible for password hashing.
On affected systems, musl rejects passwords longer than 256 bytes.
When that happens, crypt() returns an asterisk (*) to indicate an error.
Unfortunately, that's the same character used in the password field of certain accounts that aren't supposed to accept passwords.
Under the vulnerable conditions, OpenSSH compares the hashing result with the stored field. And the comparison succeeds.
The program effectively sees:
* == *
It has mistaken an error indicator for a successful password match.
There's one more detail.
For accounts without a usable password hash, OpenSSH may borrow from another account to perform a dummy password-hashing operation. This behaviour was introduced to reduce information leaks through authentication timing.
When another local account has a compatible password hash, that operation can trigger the vulnerable comparison.
The result is an authentication bypass that allows an attacker to sign in without knowing the account's password or possessing its SSH key.
Take on the OpenSSH CVE-2026-123158 room and investigate SSHole.
Which Linux Systems Are Vulnerable?
SSHole has specific requirements, which makes understanding the affected environment essential.
The vulnerable conditions include:
- OpenSSH running on Linux with musl libc and PAM disabled.
- SSH password authentication enabled.
- A target account with * in its password field.
- At least one other local account using a compatible 5 or 6 password hash.
- A target account permitted to log in through SSH.
Alpine Linux is the clearest example, although other musl-based environments may be affected if they use the same configuration.
One particularly interesting case involves Alpine's official tiny-cloud images.
Some affected images include an alpine user configured for SSH key access with passwordless doas privileges.
Under the right conditions, an attacker exploiting SSHole could access that user and escalate to root.
That doesn't mean every Alpine cloud instance is immediately vulnerable. For example, Alpine notes that its tiny-cloud images are safe on first boot, with certain later configuration changes creating the additional conditions required for exploitation.
The default OpenSSH setting PermitRootLogin prohibit-password also restricts direct password authentication to root.
Mainstream distributions such as Debian, Ubuntu and Red Hat Enterprise Linux generally use glibc and are outside this particular vulnerability's scope. Systems authenticating through PAM are likewise unaffected.
The Alpine Linux security advisory provides a detailed breakdown of the affected configurations.
Attackers Were Quick to Notice
SSHole was disclosed on 5 November 2026, and exploitation attempts followed quickly.
On 6 November, threat intelligence company Previdian reported observing attempts to exploit the vulnerability through its monitoring infrastructure.
The company also reported successful root access against an Alpine Linux honeypot running OpenSSH.
According to Previdian's vulnerability intelligence, its sensors detected exploitation attempts shortly after disclosure.
That evidence is significant, although a successful attack against a controlled honeypot doesn't establish how widely production systems have been compromised.
For exposed systems meeting the vulnerable conditions, the risk is nevertheless serious. An attacker who gains SSH access can operate with the permissions of the compromised account.
Depending on those privileges, they may be able to access sensitive files, examine configuration data, establish additional access or move towards other connected systems.
And unlike a traditional brute-force attack, the bypass doesn't require guessing passwords repeatedly.
How to Spot a Possible SSHole Attack
One of the most useful clues is a successful password login to an account that shouldn't accept password authentication.
For Alpine Linux administrators, the official advisory recommends reviewing /var/log/messages for SSH authentication records.
In particular, look for entries containing:
Accepted password for
Pay attention when these events involve accounts configured for SSH key authentication or otherwise lacking a usable password.
A successful password login for such an account deserves investigation.
Additional checks include reviewing unexpected account activity, changes to authorized_keys, newly created users and suspicious privilege escalation through doas.
For cloud and infrastructure teams, start by identifying which exposed systems run OpenSSH with musl libc and PAM disabled.
Then confirm their effective password-authentication settings and whether the vulnerable account conditions exist.
An absence of obvious suspicious login events doesn't prove an affected host was never accessed, particularly when log coverage or retention is incomplete.
If you identify signs of unauthorised access, preserve the evidence and investigate the system for persistence or additional compromise.
Take on the OpenSSH CVE-2026-123158 room and investigate SSHole.
How to Fix CVE-2026-123158
OpenSSH released version 10.6p2 on 5 November 2026 to address the vulnerability.
The official release notes confirm the authentication-bypass fix.
Alpine Linux has also released patched OpenSSH packages for affected branches, including older releases.
For example:
Older Alpine branches also received backported fixes. Check the official advisory for the appropriate package.
On Alpine Linux, the recommended update command is:
apk upgrade -U -a
After updating, restart the SSH daemon so the patched version is actually running:
rc-service sshd restart
If updating immediately isn't possible, Alpine recommends temporarily disabling password authentication by setting:
PasswordAuthentication no
Confirm that SSH key authentication works before making this change, and keep an existing administrative session available while testing the new configuration.
Disabling password authentication prevents this particular bypass, but applying the security update remains the preferred long-term fix.
Finally, review potentially compromised systems separately. Installing a patch doesn't undo access an attacker may already have obtained.
Can You Break the Password Check?
The best way to understand SSHole is to examine why the authentication process accepts a result it should reject.
In TryHackMe's OpenSSH: CVE-2026-123158 room, you can explore the vulnerability in a controlled environment and see how a password-validation mistake creates an unexpected route into a Linux system.
It's a useful challenge for anyone learning Linux security, authentication vulnerabilities or how small implementation details can undermine otherwise trusted software.
Take on the OpenSSH CVE-2026-123158 room and investigate SSHole.
Ayomide Joseph A.
