SSHhole: OpenSSH Password Bypass

A critical OpenSSH vulnerability known as SSHhole (CVE-2026-123158) reportedly allows attackers to bypass SSH password authentication on certain Linux systems using musl libc without PAM.
The vulnerability could allow unauthorized access to accounts that are normally configured for SSH key-based authentication only. Under specific conditions, attackers may also gain elevated privileges.
The issue is particularly relevant to Alpine Linux, OpenWrt, Buildroot, and Yocto environments. Administrators should check their SSH configuration and apply the security update if their systems are affected.

---

🔍 What Is the SSHhole Vulnerability?​

SSHhole is a password authentication bypass vulnerability in OpenSSH on Linux systems that use the musl C library without PAM (Pluggable Authentication Modules).

• CVE: CVE-2026-123158
• Severity: High
• CVSS Score: 8.1/10
• Disclosure date: November 5, 2026
• Affected component: OpenSSH SSH server (sshd)
• Fixed upstream version: OpenSSH 10.6p2
• Researcher: Özgün Kültekin

The OpenSSH project confirmed the security fix in its November 5 release notes.

---

⚙️ How Does SSHhole Work?​

The vulnerability is caused by how OpenSSH handles password verification errors when running with musl libc and without PAM.
Here is what happens:

1. Linux stores * in the password field of /etc/shadow for certain accounts that do not have a usable password hash.
2. When a submitted password exceeds musl's supported input length, its crypt() function returns * as an error indicator.
3. OpenSSH may incorrectly compare this error value with the stored *.
4. The comparison can succeed, allowing the attacker to authenticate without knowing the account's actual password.

The vulnerable password length is between 257 and 1,024 bytes.
Important: This is a password verification failure-handling issue, not a general bypass affecting every OpenSSH account.

---

🎯 Which Linux Systems Are Affected?​

The vulnerability affects specific OpenSSH configurations using musl libc without PAM.

System	Status
Alpine Linux 3.16–3.24	Affected
Alpine Linux edge	Affected
OpenWrt	Check configuration
Buildroot	Check configuration
Yocto	Check configuration
glibc-based Linux systems	Not affected by this flaw
PAM-enabled configurations	Not affected

For Alpine Linux, all of the following conditions must be present:

• OpenSSH runs without PAM.
• PasswordAuthentication is enabled.
• At least one account has * in its password field.
• At least one other local account has a valid $5$ or $6$ password hash.

The last condition is important because OpenSSH uses another account's salt during password verification for accounts without a usable password hash.

---

☁️ Why Are Alpine Cloud Images a Concern?​

Certain official Alpine Linux tiny-cloud images include a default alpine account with a locked password field and passwordless doas access.
Under the vulnerable configuration, an attacker may be able to authenticate as this account and then use doas to obtain root privileges.
This is especially important for administrators running older Alpine cloud images, including affected AWS AMIs and other official image formats.
However, exploitation still depends on the required SSH and account conditions being present.

---

🛡️ How to Fix the SSHhole Vulnerability​

There are two main approaches: update OpenSSH or temporarily disable password authentication.

1. Update OpenSSH​

The upstream fix is included in OpenSSH 10.6p2, released on November 5, 2026.
For Alpine Linux, fixed packages are also available through distribution-specific updates. You do not necessarily need to install upstream version 10.6p2.
Run the following command to update Alpine packages:

apk upgrade -U -a

The fixed Alpine package versions are:

Alpine branch	Fixed OpenSSH package
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

After updating, restart the SSH service:

rc-service sshd restart

Important: Updating the package alone does not replace the code running in an existing SSH daemon. Restarting sshd is necessary.

2. Disable SSH Password Authentication​

If you cannot install the security update immediately, disable password-based SSH authentication.
Open the SSH server configuration file:

sudo nano /etc/ssh/sshd_config

Find the following setting:

PasswordAuthentication yes

Change it to:

PasswordAuthentication no

Save the file and validate the SSH configuration:

sudo sshd -t

Then restart SSH:

sudo systemctl restart sshd

On Alpine Linux, use:

rc-service sshd restart

Important
Before disabling password authentication, make sure SSH key-based login works. Keep your current SSH session open and test a second connection to avoid locking yourself out.

---

🔎 How to Check Whether Your System Is Vulnerable​

If you administer an Alpine Linux server, check your SSH authentication configuration:

grep -E '^(PasswordAuthentication|UsePAM)' /etc/ssh/sshd_config

Check the installed OpenSSH package:

apk info -v openssh openssh-server openssh-server-pam

Remember that configuration files can contain additional settings and included files. The effective SSH configuration is more useful than checking a single line.
You can inspect the effective settings with:

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

If your server meets the vulnerable conditions, update it immediately or disable password authentication.

---

🚨 What Should Administrators Do?​

If you manage Linux servers or cloud infrastructure, take these precautions:

• Update affected OpenSSH packages.
• Restart the SSH daemon after updating.
• Disable password authentication until patching is complete.
• Review SSH logs for unexpected successful password logins.
• Investigate accounts with unusual access, especially key-only accounts.
• Review doas activity and newly created users.
• Rebuild or update older Alpine cloud images.

On Alpine Linux, check /var/log/messages for unexpected entries such as Accepted password for involving accounts that should not accept password authentication.
If you cannot rule out unauthorized access, treat the system as potentially compromised and investigate it accordingly.

---

Frequently Asked Questions​

------------------

Does SSHhole affect all Linux distributions?​

No. It specifically affects certain OpenSSH configurations using musl libc without PAM. Standard glibc-based configurations are not affected by this particular vulnerability.

Can attackers access accounts configured for SSH keys only?​

Yes. Certain accounts with * in their password field can be vulnerable under the required conditions, even if they were intended to use SSH keys only.

Is OpenSSH 10.6p2 required to fix the issue?​

Not necessarily. It contains the upstream fix, but Linux distributions such as Alpine can backport the security patch into older package versions.

Does disabling SSH password authentication protect against SSHhole?​

Yes. Setting PasswordAuthentication no and restarting the SSH daemon prevents exploitation through this password authentication path.

Can SSHhole lead to root access?​

Potentially, yes. For example, certain vulnerable Alpine cloud images include an alpine account with passwordless doas privileges.