Security teams issued emergency patches on 5 November 2026 after researchers disclosed an OpenSSH authentication bypass flaw affecting Linux distributions built on the musl C library. The bug allows an attacker to log into password-disabled accounts on Alpine Linux and other distributions by entering an input longer than 256 bytes.
Key points
- An OpenSSH authentication bypass vulnerability lets attackers log into disabled Linux accounts by sending a password exceeding 256 bytes.
- Systems combining OpenSSH, musl libc, and password authentication are vulnerable, including default Alpine Linux installations and cloud instances.
- Security researcher Ozgun Kultekin discovered the decade-old flaw by deploying automated AI agents across 17,600 test configurations.
- OpenSSH 10.6p2 and Alpine Linux patches are available, while administrators can also block exploitation by disabling SSH password authentication.
How oversized passwords trigger the bypass
Linux administrators often prevent password logins on service accounts by placing an asterisk in the password hash field of the /etc/shadow file. Because an asterisk is not a valid cryptographic hash, the operating system normally rejects every password attempt against that account.
The flaw, dubbed SSHhole, breaks that security assumption. In 2016, OpenSSH developers introduced a patch for a username enumeration vulnerability tracked as CVE-2016-6210. That fix ensured the server spent equal time hashing passwords for valid and invalid accounts, preventing attackers from timing responses to map active usernames.
As part of that defence, OpenSSH began computing password hashes even when an account possessed an unusable hash such as an asterisk. Under standard GNU C Library (glibc) environments, invalid inputs or hashing failures return null or safe error values.
On systems running the alternative musl C library, the standard crypt function behaves differently. When a user submits a password longer than the 256-byte limit of musl libc, the function encounters an error and returns an asterisk. OpenSSH then compares that returned asterisk against the stored asterisk in /etc/shadow, treats the two characters as an exact match, and grants the attacker an interactive session.
The researcher who identified the issue, Ozgun Kultekin, published technical details on his vulnerability advisory site. Kultekin found the bug using autonomous AI agents that executed approximately 17,600 authentication permutations involving malformed hashes, odd server flags, and oversized input strings.
Why Alpine Linux faces the biggest exposure
Exploiting the vulnerability requires five specific conditions. The host must run OpenSSH on a musl-based operating system with Pluggable Authentication Modules (PAM) disabled, allow SSH password authentication, contain at least one account locked with an asterisk, and have another account configured with a valid password hash.
Mainstream enterprise distributions such as Debian, Ubuntu, and Fedora rely on glibc and default PAM configurations, which protect them from the attack. Distributions running musl, such as Buildroot, Yocto, Void Linux, and OpenWrt, contain the affected code paths. OpenWrt uses Dropbear for authentication by default, reducing its immediate exposure unless administrators replace it with OpenSSH.
Alpine Linux represents the most serious security concern. Alpine uses musl by default, disables PAM in its official OpenSSH server package, and enables SSH password authentication unless administrators manually reconfigure it.
Because Alpine serves as a common lightweight base image for millions of Docker containers, Kubernetes pods, and cloud servers, vulnerable deployments are widespread across data centres and home networks.
Cloud environments face heightened privilege escalation risks. Official Alpine Linux virtual machine images on Amazon Web Services and Microsoft Azure feature a default alpine user account. That account uses an asterisk in its password field but possesses passwordless doas administrative permissions. An attacker who bypasses the login prompt can gain root access on the cloud virtual machine in seconds.
Emergency patches and disputed responsibility
The OpenSSH development team released version 10.6p2 on 5 November 2026, while Alpine Linux published an update to its package repositories alongside the project’s advisory note.
In release notes for the new build, the OpenSSH project confirmed that developers published a fix to prevent the server from accepting error strings as successful authentications.
Musl libc author Rich Felker also issued an advisory on the Openwall security mailing list. Both software teams debated where the core failure occurred. Maintainers argued over whether musl erred by returning an asterisk on cryptographic failures or whether OpenSSH erred by comparing error strings directly against shadow files.
While internet-facing Alpine instances pose an immediate target, security analysts warned that internal networks remain at risk. An attacker with internal network access or VPN credentials could scan internal subnets for exposed SSH daemons and bypass authentication on container fleets.
How administrators can mitigate and audit servers
Administrators running Alpine Linux can install the fixed OpenSSH package immediately through the package manager by running apk upgrade openssh.
For systems that cannot be rebooted or updated immediately, administrators can neutralise the threat by disabling password logins entirely. Setting PasswordAuthentication to no in the sshd_config file and restarting the SSH daemon blocks the exploit chain without affecting public key authentication.
Security teams can also audit system logs for signs of past compromise. On Alpine Linux, running grep “Accepted password” /var/log/messages reveals whether any password authentications succeeded. If an account such as alpine appears in those logs, administrators can run grep ‘^alpine:’ /etc/shadow to inspect its configuration. A successful password entry for an account that contains an asterisk in the shadow file indicates that an attacker may have exploited the bypass.
