SSHHole (CVE-2026-123158) is an SSH password authentication bypass affecting certain Linux systems running OpenSSH with musl libc and PAM disabled.

Disclosed on November 5, 2026, it can let a remote attacker access an eligible account without knowing its password. Alpine Linux is a prominent affected platform.

The priority: install a fixed OpenSSH package and restart sshd. If patching must wait, disable password authentication.

Last reviewed: November 6, 2026.

SSHHole at a glance

The OpenSSH release notes confirm the workaround and credit Özgün Kültekin of Wakefield with reporting the issue.

Which systems are affected?

The documented attack requires the following conditions together:

• The server runs an unpatched OpenSSH build using musl libc.
• PAM is unavailable or disabled, including builds running with UsePAM no.
• The server permits password authentication: PasswordAuthentication yes.
• An account permitted to log in has a password field containing exactly *.
• Another local account has a $5$ or $6$ password hash.
• The attacker can reach the SSH service and identify a target username.

These prerequisites are detailed in the Alpine security advisory and technical analysis from IONIX.

Using SSH keys does not, by itself, prevent this attack. An account intended for key-only access can still be exposed if the server accepts passwords and the other conditions hold.

The researcher’s disclosure distinguishes this configuration from standard glibc-based systems such as Debian and Ubuntu, PAM-enabled authentication, Dropbear, and OpenBSD, which are outside this bypass’s scope. Custom builds should be assessed by their actual authentication stack.

An Alpine container without a running SSH server has no SSHHole login endpoint.

How does the authentication bypass work?

A password field containing * is a marker intended to prevent password authentication; it is not an empty password.

In the affected authentication path, OpenSSH hashes a supplied password and compares the result with the stored field. When that field cannot provide a usable salt, OpenSSH can borrow one from another account.

For the relevant musl hashing routines, a password exceeding 256 bytes causes crypt() to return * as an error indicator. If the target account’s stored field is also *, the comparison succeeds. The documented input range is 257–1,024 bytes.

The researcher’s explanation traces how these behaviors interact. The OpenSSH fix adds a minimum stored-hash length check before accepting a match. OpenSSH describes the release as a workaround for a root cause outside sshd.

Does SSHHole give attackers root access?

The immediate access is to the targeted account. Direct root password login also depends on PermitRootLogin; its default prohibit-password setting blocks that route.

However, a compromised account may have elevated privileges. Alpine warns that affected tiny-cloud images can expose an alpine account with passwordless doas once another account has a suitable password hash. That can turn account access into root access.

How to fix SSHHole

Install the upstream fix or a patched distribution package

For upstream builds, use OpenSSH 10.6p2 or a later fixed release. For distribution packages, follow your distributor’s advisory: backports can fix the issue without adopting the upstream version number.

Alpine lists these fixed package versions:

Source: Alpine Linux security advisory. Emergency patches for older branches do not imply ongoing support.

Restart sshd after updating. Installing a package alone leaves the old daemon running. Verify the installed server package revision against the advisory; ssh -V reports the client version and does not establish whether a server has a backported fix.

If patching must wait, disable password authentication

Set the following in the server’s effective SSH configuration:

PasswordAuthentication no

Validate the configuration before restarting the service. Check applicable Match blocks, confirm key access works, and keep an existing administrative session open while testing a new connection.

Review authentication logs

Investigate successful password logins to accounts that should never accept passwords. Pay particular attention to Accepted password for log entries for accounts whose password field is *, and correlate suspicious access with subsequent privilege use and host changes.

Monitor OpenSSH vulnerabilities with OpenCVE

A CVE record is only the starting point: what matters next is how it lines up with your packages, SSH configuration, and account privileges.

OpenCVE helps you watch the vendors and products you care about, follow changes to advisories, and notify your team through automations.