Summary:
OpenSSH has released emergency version 10.6p2 to fix a critical authentication bypass that lets attackers log in to accounts with no password set, such as SSH key-only accounts, on Alpine Linux servers running the standard openssh-server package. An attacker needs only network access, an account name, and a password between 257 and 1,024 bytes long, and the attack succeeds on every try with a single connection. The flaw results from how sshd interacts with the musl C library used by Alpine, and exposure requires password logins to be enabled, which is the default, and at least one other account with a password hash. Alpine has published fixed packages for all releases back to 3.16, no attacks have been reported, and no CVE had been assigned as of November 5, 2026.
Technical Description:
The vulnerability affects the OpenSSH server (sshd) on Alpine Linux systems where passwords are checked without the Pluggable Authentication Module (PAM) interface, which is how Alpine's openssh-server package is built. When sshd checks a password itself, it hashes the attempt with the C library function crypt() and compares the result with the stored password field. Accounts with no password have only * in that field, which is too short to hold a salt, so sshd borrows the salt of another account that has a real hash. For $5$ and $6$ hashes, musl's crypt() refuses passwords longer than 256 bytes and returns *, which matches the stored * and lets the login succeed. The upper end of the range is sshd's own limit of 1,024 bytes per password.
A server is exposed when all four conditions hold: it runs openssh-server (built without PAM) or openssh-server-pam with UsePAM no; PasswordAuthentication is yes, which is the OpenSSH default; an account has * in its password field; and at least one other local account has a password hash starting with $5$ or $6$. Accounts without a password include key-only users, directory users from musl-nscd, root, which has shipped as root:* since about Alpine 3.16 and is protected by the default PermitRootLogin prohibit-password setting, and the alpine user in official tiny-cloud cloud images. One account with a password is enough to expose every account without one, and the attacker needs only the name of an account with no password.
The tiny-cloud images from 3.18.11 through 3.24.3 give the alpine user passwordless doas, so they are safe at first boot but become open to attack once any $6$ hash exists on the machine, allowing an attacker to log in as alpine and become root. Non-Linux systems, glibc-based Linux systems, systems that check passwords through PAM, containers that do not run sshd, systems with PasswordAuthentication no, cloud-init images, and accounts locked with ! are not affected. Reporter Özgün Kültekin of Wakefield names OpenWrt, Buildroot, and Yocto as other musl-based systems to check, although Dropbear is not affected.
| CVE | CVSS | Vulnerability Type | Affected Product | Patch Version |
| Not assigned | NA (Critical) | Authentication Bypass (musl crypt() / sshd) | OpenSSH sshd on Alpine Linux | OpenSSH 10.6p2 |
Exploitation Demonstration:
· The attacker identifies an Alpine Linux server exposing SSH with password authentication enabled and learns the name of an account with no password set, such as alpine, root, or a key-only user.
· The attacker connects to sshd and submits a password between 257 and 1,024 bytes long for that account.
· sshd borrows the salt of another account with a $5$ or $6$ hash and calls musl's crypt(), which refuses passwords over 256 bytes and returns *.
· The returned * matches the * stored for the passwordless account, so sshd accepts the login on the first attempt, using a single connection.
· The attacker gains a shell as that account and can escalate to root if the account allows it, such as the alpine user's passwordless doas in tiny-cloud images.
Ease of Exploitation:
The vulnerability is easy to exploit: it requires only network access to the SSH service, an account name, and a long password, needs no prior authentication, and succeeds on every try with a single connection according to Alpine's advisory. The main constraint is that the target must meet the four exposure conditions, including password logins enabled, which is the OpenSSH default, and at least one account with a $5$ or $6$ hash. OpenSSH rates the flaw critical and no attacks have been reported. The OpenSSH project also noted that long embargoes are dangerous because AI agents have recently rediscovered the same bugs, sometimes within hours.
Conclusion:
The flaw shows how a long-standing interaction between OpenSSH and the musl C library can turn a default configuration into an authentication bypass, with a root cause that lies outside sshd. Organizations running Alpine Linux, including containers and cloud images that run sshd, should update packages and restart sshd immediately, or disable password authentication where updating is not yet possible. If a login cannot be ruled out, the machine should be treated as compromised.
Impact:
Successful exploitation allows an attacker to log in as any account with no password without credentials, including key-only service accounts and cloud image users, and potentially to become root through privilege escalation such as doas. This could lead to full compromise of the server, data theft, installation of persistent access, and lateral movement. Exposure is not limited to Alpine, as other musl-based systems that run the OpenSSH server may also be affected.
IOC and Context Details:
| Topics | Details |
| Tactic Name | Initial Access, Privilege Escalation |
| Technique Name | External Remote Services; Exploit Public-Facing Application |
| Sub Technique Name | NA |
| Attack Type | Vulnerability |
| Targeted Applications | OpenSSH server (sshd) on Alpine Linux and other musl-based systems; Alpine tiny-cloud images |
| Region Impacted | Global |
| Industry Impacted | All industries running Alpine Linux servers, containers, and cloud images with SSH exposed |
| IOC's | sshd log entries: Accepted password for an account with no password (for example alpine, root, or a key-only user). Unexpected doas use, especially by the alpine account. Recently created users, files, and authorized_keys entries. |
| CVE | Not assigned (as of November 5, 2026) |
Recommended Actions:
· Update Alpine packages with apk upgrade -U -a and restart sshd with rc-service sshd restart, as the package upgrade does not restart the running sshd; fixed packages exist for all releases back to 3.16, including point releases 3.21.10, 3.22.8, 3.23.8, and 3.24.4.
· Update cloud instances started from tiny-cloud images older than those point releases, and move self-built OpenSSH to version 10.6p2.
· If updating is not yet possible, confirm key-based login works, keep the current session open, then set PasswordAuthentication no, including inside Match blocks, check with sshd -t, restart sshd, and verify with sshd -T.
· Disable SSH on affected systems that do not need it, as the OpenSSH project advises, and restrict SSH exposure to trusted networks.
· Review /var/log/messages for sshd lines reading Accepted password for an account that has no password, such as alpine, root, or a key-only user.
· On exposed machines, review doas use, recently created users, files, and authorized keys; if a login cannot be ruled out, treat the machine as compromised.
· Inventory Alpine and other musl-based systems, such as OpenWrt, Buildroot, and Yocto, that run the OpenSSH server; Dropbear is not affected.
· Audit local accounts for * password fields and $5$ or $6$ hashes, and lock accounts that should not have passwords with ! rather than *.
Reference:
https://thehackernews.com/2026/11/openssh-issues-emergency-fix-for-flaw.html