SSHole: The OpenSSH Password Bypass Affecting Some musl Linux Systems

Security note: SSHole, tracked as CVE-2026-123158, is a serious authentication issue affecting some OpenSSH installations that use musl libc. Under specific conditions, an attacker may authenticate as an account whose password is supposed to be disabled by submitting an oversized password—typically between 257 and 1,024 bytes.

Not every Linux distribution or OpenSSH server is affected. The risk depends on the operating system's C library, OpenSSH configuration, authentication stack, and the state of the target account. Alpine Linux deserves particular attention because it is widely used for lightweight servers, cloud images, and Docker base images.

What is SSHole?

Linux accounts commonly use a special value such as * in /etc/shadow to indicate that password authentication is disabled. This is normal for accounts intended to use SSH keys only, service accounts, and other accounts that should never accept a password.

The issue arises from the interaction between OpenSSH and the crypt() function provided by musl libc. For passwords longer than 256 bytes, musl's password-hashing implementation can fail and return the same * value used to represent a locked password. In an affected, non-PAM OpenSSH setup, the failed result may compare equal to the account's locked-password field.

That can turn a deliberately disabled password into an authentication bypass: a sufficiently long password may be accepted for an account that should not accept passwords at all. The flaw does not bypass a normal, valid password hash.

Which systems may be affected?

The reported vulnerability requires a combination of conditions:

• OpenSSH is running with musl libc rather than glibc.
• Password authentication is enabled.
• OpenSSH is not using PAM; this is a common configuration in Alpine's OpenSSH package.
• The target has an account whose password field is *.
• Another account has a valid password hash, which can provide the salt OpenSSH uses during its password check.
• The attacker submits an oversized password.

Alpine Linux is the most common environment to investigate, but musl is also used by distributions and embedded systems such as OpenWrt, Buildroot, and Yocto-based systems. Systems using glibc, PAM-based authentication, Dropbear, or non-Linux platforms are not affected by this specific attack according to the available technical analysis.

Why Alpine and Docker users should pay attention

Many Docker images are based on Alpine because of its small footprint. Most containers do not run an SSH server, so simply using an Alpine base image does not automatically make an application vulnerable. The concern is greatest for Alpine hosts, virtual machines, cloud images, or containers that install and expose openssh-server.

Some Alpine cloud images also include default accounts configured for key-based access and passwordless privilege escalation. An unexpected login to such an account could therefore have consequences beyond the initial SSH session. Review any image or server that runs an SSH daemon, especially if it allows password authentication or contains accounts configured for key-only access.

How to check your systems

First, identify the C library and OpenSSH version on each exposed system:

ldd --version
ssh -V
sshd -T | grep -Ei 'passwordauthentication|usepam'

On Alpine, review the installed package and available updates:

apk policy openssh
apk version -l '<'

Also review which accounts have locked password fields. Access to /etc/shadow normally requires root privileges:

sudo awk -F: '$2 ~ /^\*/ { print $1 " has a locked password field" }' /etc/shadow

Do not test a production system by guessing passwords or by sending credentials to a third-party demonstration site. Use the official SSHole demonstration for background, and perform any validation only in an isolated system that you own.

Recommended fix

OpenSSH 10.6p2 addresses the issue. Install the patched OpenSSH package—or the security update supplied by your distribution—as soon as possible, then restart the SSH service. On Alpine, the general package-update workflow is:

sudo apk update
sudo apk upgrade openssh

Use the package version provided by your Alpine release and confirm the fix in the relevant Alpine security advisory or package changelog. Do not assume that upgrading an unrelated application image updates an SSH daemon on a separate host.

If you cannot update immediately, disable password authentication and rely on verified SSH keys:

sudo sh -c 'printf "%s\n" "PasswordAuthentication no" > /etc/ssh/sshd_config.d/00-no-passwords.conf'
sudo sshd -t
sudo rc-service sshd restart

Before restarting SSH, confirm that you have a working key-based session and a separate recovery path. A configuration mistake can lock administrators out.

Check for exploitation

Threat researchers have reported exploitation attempts shortly after the vulnerability was disclosed, including successful access to an Alpine Linux honeypot. A vulnerable configuration does not prove that an intrusion occurred, but exposed systems should be investigated promptly.

Review SSH authentication logs for unexpected successful password logins involving accounts that should be key-only or locked. On Alpine, a starting point is:

grep "Accepted password" /var/log/messages

Pay particular attention to an account such as alpine or root if its password field is locked:

grep '^alpine:' /etc/shadow

If the logs show a successful password login for an account whose shadow entry contains *, treat it as a possible compromise. Isolate the host as appropriate, preserve evidence, review command history and persistence locations, inspect newly created users and authorized keys, and rotate credentials or secrets that may have been accessible.

Additional defensive steps

• Disable SSH password authentication wherever operationally practical.
• Limit SSH exposure with firewall rules, VPN access, security groups, or an allowlist.
• Keep OpenSSH, musl, and the base operating system updated.
• Review cloud-init and image defaults, including default users on Alpine cloud images.
• Do not expose an SSH daemon in a container unless it is genuinely required.
• Inventory routers, access points, NAS systems, appliances, VMs, containers, and development environments that may include an SSH server.
• Rotate credentials and investigate the host if you find an unexpected successful authentication.

Bottom line

Audit every internet-facing OpenSSH server that uses musl, with Alpine Linux at the top of the list. Update OpenSSH, turn off password authentication when possible, and verify your logs. The issue is configuration-dependent, but the potential impact—logging in as an account that should never accept a password—makes a prompt review worthwhile.

Further reading

• SSHole technical explanation and demonstration
• The Hacker News: Hackers Target OpenSSH SSHole Flaw Within Hours of Disclosure
• BleepingComputer: OpenSSH flaw lets attackers log into password-disabled Linux accounts

Confirm remediation guidance against your distribution's official security advisory before deploying it broadly.