SSHole (CVE-2026-123158): Critical OpenSSH Vulnerability Allows Passwordless Access to Linux Servers

A newly disclosed vulnerability in OpenSSH is raising concerns among Linux administrators and cybersecurity professionals. Named SSHole (CVE-2026-123158), the security flaw allows remote attackers to bypass SSH password authentication and access certain Linux accounts without knowing their passwords.

The vulnerability primarily affects systems running Alpine Linux and other distributions that use the musl C library without PAM. Even more concerning, security researchers have already reported successful exploitation attempts.

SSHole Vulnerability: Quick Summary

SSHole is a high-severity OpenSSH authentication bypass vulnerability (CVSS 8.1) that allows remote attackers to log into certain passwordless Linux accounts by submitting an unusually long password. Systems running vulnerable OpenSSH configurations on musl-based Linux distributions are at risk. Administrators should immediately install the available security updates or temporarily disable SSH password authentication.

Table of Contents

1. What Is the SSHole Vulnerability?
2. How Does the SSHole Attack Work?
3. Which Linux Distributions Are Affected?
4. What Can Attackers Do After Exploitation?
5. Has SSHole Already Been Exploited?
6. How to Check Whether Your Linux Server Is Vulnerable
7. How to Protect Your Linux Server
8. How to Detect Potential SSHole Attacks
9. Conclusion
10. Frequently Asked Questions

1. What Is the SSHole Vulnerability?

SSHole is a security vulnerability affecting OpenSSH, specifically the SSH server component (sshd).

It allows an unauthenticated remote attacker to bypass password authentication under certain system configurations.

The vulnerability is tracked as CVE-2026-123158 and has received a CVSS 3.1 score of 8.1 (High).

Security researcher Özgün Kültekin discovered the issue and reported it to the OpenSSH project.

The vulnerability results from an unexpected interaction between two components:

• OpenSSH: The implementation responsible for handling SSH connections and authenticating remote users.
• musl libc: A lightweight C standard library used by Alpine Linux and several other Linux-based systems.

The problem occurs when OpenSSH handles password verification errors returned by musl libc. Under specific conditions, the authentication process incorrectly accepts a password that should have been rejected.

The issue is particularly concerning because the attacker does not need to know the account’s actual password or possess its SSH private key.

2. How Does the SSHole Attack Work?

Understanding this vulnerability requires looking at how Linux handles user passwords and how OpenSSH verifies authentication requests.

Understanding passwordless Linux accounts

Linux stores local account information in /etc/shadow.

When an account has a password, this file contains its password hash.

However, some accounts are intentionally configured without password authentication. Their password field may contain an asterisk (*).

For example:

root:*

This configuration normally prevents password-based authentication.

Administrators commonly use such accounts when they want users to authenticate through SSH keys instead of passwords.

Where does the vulnerability occur?

On systems using musl libc without PAM, OpenSSH performs password verification using the C library’s crypt() function.

Under normal circumstances, the function processes a password and compares the resulting hash with the account’s stored password hash.

However, musl libc has a limitation when processing unusually long passwords.

When the supplied password exceeds 256 bytes, crypt() returns an asterisk (*) to indicate an error.

This creates an unexpected authentication problem.

Consider the following sequence:

1. An attacker connects to a vulnerable SSH server.
2. The attacker identifies an account configured without a password, whose password field contains *.
3. The attacker submits an unusually long password between 257 and 1,024 bytes.
4. musl libc rejects the oversized password and returns *.
5. OpenSSH compares this result with the account’s stored password field.
6. Both values match, and the authentication process incorrectly accepts the login.

As a result, an attacker can access an account without knowing its actual password.

Why does this happen?

The underlying problem is an incorrect interpretation of an error value.

The asterisk (*) has two different meanings in this situation:

• In /etc/shadow, it indicates that an account has no usable password.
• In musl libc, it can indicate that password hashing failed.

OpenSSH fails to distinguish these situations correctly in the vulnerable configuration.

This is why an error returned by the password-processing function can accidentally become a successful authentication result.

3. Which Linux Distributions Are Affected?

The vulnerability does not affect every Linux distribution.

It primarily targets systems using musl libc with OpenSSH configured without PAM.

Confirmed affected configurations

Alpine Linux is the main affected distribution because its default OpenSSH server package is built without PAM.

According to Alpine Linux’s security advisory, affected releases include:

• Alpine Linux 3.16 to 3.24.
• Alpine Linux Edge.

The vulnerability can also affect other Linux environments using the same combination of components.

These include configurations based on:

• OpenWrt
• Buildroot
• Yocto

However, administrators should verify the exact OpenSSH build and authentication configuration rather than assuming every installation of these platforms is vulnerable.

Systems that are not affected

The following configurations are not affected by this specific vulnerability:

System or configuration	Status
Alpine Linux with vulnerable OpenSSH configuration	Affected
OpenSSH using musl without PAM	Potentially affected
Debian Linux using glibc	Not affected
Ubuntu Linux using glibc	Not affected
Fedora using glibc	Not affected
OpenSSH using PAM with UsePAM yes	Not affected
Systems using Dropbear SSH	Not affected
Systems with password authentication disabled	Not affected

Important: Running Alpine Linux alone does not automatically mean that a server is vulnerable. The attack requires several conditions to be present simultaneously.

4. What Can Attackers Do After Exploitation?

The immediate consequence is unauthorized access to an SSH account.

However, the actual impact depends on the privileges assigned to the compromised account.

Potential consequences include:

• Access to sensitive files and configuration data.
• Unauthorized access to application directories.
• Theft of application credentials and deployment secrets.
• Installation of malicious scripts or backdoors.
• Modification of system configurations.
• Lateral movement to other infrastructure.
• Privilege escalation to root when additional conditions allow it.

One particularly concerning example involves Alpine Linux cloud images.

Some official Alpine tiny-cloud images include an alpine account configured without a password and with passwordless doas privileges.

If the vulnerable authentication conditions are met, an attacker could access this account and potentially obtain root privileges using doas.

This demonstrates why compromising a seemingly unprivileged account can still create a serious security incident.

5. Has SSHole Already Been Exploited?

Yes. The situation became more concerning on November 6, 2026.

According to cybersecurity reporting from The Hacker News and Help Net Security, threat intelligence company Previdian detected exploitation attempts less than nine hours after the vulnerability became public.

Researchers also confirmed successful root access on an Alpine Linux and OpenSSH honeypot.

The attackers reportedly used oversized passwords to bypass authentication before executing reconnaissance commands, including:

id
uname
hostname

These commands help attackers identify the compromised system, determine their current privileges and collect basic information about the operating environment.

The incident demonstrates how quickly attackers can turn a newly disclosed vulnerability into an operational attack.

For administrators running exposed Alpine Linux servers, delaying security updates is therefore particularly risky.

6. How to Check Whether Your Linux Server Is Vulnerable

Linux administrators should investigate their SSH configuration, installed packages and account settings.

The following checks can help identify potentially vulnerable Alpine Linux systems.

Step 1: Identify your Linux distribution

Run:

cat /etc/os-release

This displays information about your Linux distribution and version.

Step 2: Check the installed OpenSSH packages

On Alpine Linux, run:

apk info | grep openssh

This helps identify installed OpenSSH packages.

Step 3: Check SSH authentication settings

Run:

sshd -T | grep -Ei 'passwordauthentication|usepam'

Pay particular attention to:

passwordauthentication yes
usepam no

This combination requires immediate investigation on systems using musl libc.

Remember that the effective configuration may include additional settings and conditional Match blocks.

Step 4: Check passwordless accounts

The following command displays accounts whose password field contains an asterisk:

awk -F: '$2 == "*" {print $1}' /etc/shadow

For example:

root
alpine

These accounts may be relevant to the vulnerability.

Security note: Run this command with appropriate administrative privileges. Do not publish or share the contents of /etc/shadow.

Step 5: Check whether accounts use SHA-256 or SHA-512 password hashes

The vulnerable configuration also requires at least one local account with a SHA-256 or SHA-512 password hash.

These hashes commonly begin with:

• $5$ for SHA-256.
• $6$ for SHA-512.

An administrator can inspect the relevant entries locally:

awk -F: '$2 ~ /^\$[56]\$/ {print $1}' /etc/shadow

If the required conditions are present, treat the system as potentially vulnerable and prioritize the security update.

7. How to Protect Your Linux Server

OpenSSH and Alpine Linux have released security fixes.

The recommended approach is to update the affected packages and restart the SSH service.

Method 1: Update OpenSSH on Alpine Linux

Run:

apk update
apk upgrade -U -a

Then restart the SSH service:

rc-service sshd restart

Important: Installing the updated package does not automatically replace the currently running SSH daemon. Restarting the service is necessary to load the patched version.

Alpine has published fixed packages for supported and older branches.

The following releases contain the security fix:

Alpine release	Fixed package version
3.24	10.3_p1-r2
3.23	10.2_p1-r1
3.22	10.0_p1-r11
3.21	9.9_p2-r1
3.20	9.7_p1-r6
3.19	9.6_p1-r3
3.18	9.3_p2-r4
3.17	9.1_p1-r7
3.16	9.0_p1-r6
Edge	10.6_p2-r0

These are Alpine package versions, not necessarily the upstream OpenSSH version numbers.

For other distributions and custom builds, install the vendor-provided patched package.

Method 2: Disable SSH password authentication

If you cannot install the security update immediately, disabling password authentication is an effective temporary mitigation.

Open the SSH configuration file:

vi /etc/ssh/sshd_config

Find:

PasswordAuthentication yes

Change it to:

PasswordAuthentication no

Save the configuration and validate it:

sshd -t

If the configuration passes validation, restart SSH:

rc-service sshd restart

Verify the effective setting:

sshd -T | grep passwordauthentication

Expected output:

passwordauthentication no

Important: Before disabling password authentication, make sure SSH key authentication works. Keep your current SSH session open and test a new connection before closing it. This helps prevent accidental loss of remote access.

Method 3: Restrict SSH network access

Another important security measure is limiting access to the SSH service.

Instead of exposing port 22 to the entire internet, consider:

• Allowing SSH connections only from trusted IP addresses.
• Using a VPN for remote administration.
• Restricting access through firewall rules.
• Monitoring internet-facing SSH services.
• Removing unnecessary SSH services from containers and appliances.

Reducing SSH exposure does not replace patching, but it can reduce the attack surface.

8. How to Detect Potential SSHole Attacks

Updating your server is essential, but administrators should also investigate whether attackers accessed the system before the patch was installed.

Alpine Linux recommends checking SSH authentication logs.

Check successful password authentication attempts

Run:

grep "Accepted password" /var/log/messages

Look for successful password authentication involving accounts that should not accept passwords, such as:

• root
• alpine
• Key-only accounts

For example:

Nov  6 03:14:07 server sshd[2211]: Accepted password for alpine from 203.0.113.66 port 41822 ssh2

If the alpine account is configured with * in /etc/shadow, a successful password login deserves immediate investigation.

Investigate suspicious activity

Administrators should also investigate:

1. Unexpected SSH login attempts.
2. Newly created Linux accounts.
3. Unexpected changes to authorized_keys.
4. Suspicious doas or privilege-escalation activity.
5. Unusual processes and running services.
6. Unexpected modifications to system files.

If you cannot rule out unauthorized access, treat the server as compromised.

This may require isolating the machine, rotating credentials and SSH keys, investigating persistence mechanisms and rebuilding the system from a trusted image.

Conclusion

The SSHole vulnerability (CVE-2026-123158) highlights how an unexpected interaction between system libraries and authentication software can create a serious security weakness.

Although the vulnerability primarily affects specific musl-based Linux configurations, its impact can be significant because SSH provides direct access to critical infrastructure.

The availability of security updates and the reported exploitation attempts make this an urgent issue for administrators running Alpine Linux and other potentially affected environments.

If you manage Linux servers, review your OpenSSH configuration, install the latest security updates and verify that the running SSH daemon uses the patched version. Do not wait for evidence of compromise before taking action.

Frequently Asked Questions (FAQ)

1. What is the SSHole vulnerability?

SSHole is an OpenSSH authentication bypass vulnerability tracked as CVE-2026-123158. It allows attackers to access certain passwordless Linux accounts by submitting an unusually long password under specific system configurations.

2. What is the severity of CVE-2026-123158?

The vulnerability has a CVSS 3.1 score of 8.1, classified as High.

3. Is Ubuntu affected by SSHole?

Standard Ubuntu installations use glibc rather than musl libc and are not affected by this specific vulnerability.

4. Is Debian Linux affected?

No. Standard Debian installations use glibc, so they are not affected by this particular authentication bypass.

5. Does SSHole allow attackers to obtain root access?

Potentially, yes. Attackers may obtain root privileges if they compromise an account with administrative permissions or an account that can escalate privileges through tools such as doas.

6. How can I protect my Alpine Linux server?

Install the patched OpenSSH package, restart the SSH daemon and verify that the running service uses the updated version. If you cannot update immediately, disable password-based SSH authentication.

7. Does changing my SSH password fix the vulnerability?

No. Changing passwords alone does not resolve the underlying problem. The vulnerability involves how OpenSSH handles password verification errors. You must install the security update or apply the recommended temporary mitigation.

8. Is SSH key authentication affected?

The vulnerability targets password authentication. Systems with password authentication completely disabled are not affected by this attack path.

9. What is the patched OpenSSH version?

The upstream fix was released in OpenSSH 10.6p2. Alpine Linux also provides patched packages for its different release branches.

10. Has SSHole been exploited in the wild?

Yes. On November 6, 2026, security researchers reported exploitation attempts and confirmed successful root access on an Alpine Linux honeypot.