# OpenSSH 'sshole' bug lets anyone log into passwordless accounts on Alpine Linux: patch CVE-2026-123158 now

> A logic flaw in how OpenSSH checks passwords on musl-based systems lets an attacker log into accounts that have no password by sending a very long one. OpenSSH 10.6p2 and Alpine's backported packages fix it; anyone running sshd on Alpine hosts or containers should update or switch off password logins today.

Published Nov 5, 2026 by TechMeasured Staff · Security · Canonical: https://techmeasured.com/security/openssh-sshole-cve-2026-123158-alpine-musl-password-bypass-what-to-do

The **OpenSSH** project shipped **version 10.6p2** on **November 5** to fix **CVE-2026-123158**, nicknamed "**\*sshole**": on Linux systems built with the **musl** C library and running sshd without PAM — the default on **Alpine Linux** — an attacker who can reach the SSH port can log into an account that has no password simply by sending a very long password. Alpine published fixed packages the same day for every supported branch back to 3.16. MITRE rates the flaw **8.1 (High)** on CVSS 3.1, according to OX Security and Cycode.

Why it matters: Alpine is the base of a huge share of Docker images and small cloud VMs, and musl also underpins embedded build systems. The bug is a simple logic error rather than memory corruption, so it is easy to reproduce, and the fix landed within about a day of the report — OpenSSH's maintainers now skip long embargoes because, as Cycode and OX relay, AI tools can rediscover a reported bug within hours. Defenders should assume working exploits will circulate quickly.

## How the bypass works

Without PAM, OpenSSH verifies a password by hashing it with the C library's `crypt()` function and comparing the result with the stored hash in `/etc/shadow`. According to administrator.de and Tech Insider:

- On musl, `crypt()` rejects passwords longer than 256 bytes and returns the string `*` instead of a hash.
- Accounts that have no usable password — locked or key-only users — typically have `*` in their shadow password field.
- When the two `*` strings match, sshd treats the login as successful. One report gives a working password length of 257 to 1,024 bytes.

administrator.de says the behaviour grew out of several changes made between 2012 and 2016 and went unnoticed for roughly a decade. The issue was reported by **Özgün Kültekin** of Wakefield.

## Are you affected?

OX Security and Cycode say a system is exposed only when **all** of these are true:

| Condition | Default on Alpine? |
|---|---|
| sshd built against musl and running **without PAM** (`openssh-server`, or `openssh-server-pam` with `UsePAM no`) | Yes |
| `PasswordAuthentication` enabled | Yes |
| At least one account with **no password** | Varies — key-only users count |
| At least one other account with a real password hash | Varies |

Two details raise the stakes. Alpine's official cloud images from **3.18.11 to 3.24.3** ship an `alpine` user with no password that can run `doas` as root, the researchers say, so a vulnerable VM can become a root compromise. Root itself is protected under the default `PermitRootLogin prohibit-password`.

**Not affected**, per the same reports: glibc-based distributions such as Debian, Ubuntu and Fedora; any sshd that authenticates through PAM; and Dropbear, which is OpenWrt's default SSH server. Tech Insider notes that musl-based OpenWrt, Buildroot and Yocto builds are in scope only if they ship OpenSSH configured as above.

On containers, OX says several popular Docker Hub SSH images — Gitea, Gogs, the Jenkins SSH agent, and linuxserver's openssh-server unless `PASSWORD_ACCESS=true` — disable password logins by default, but a small number were exposed under their documented setup. Images built on Alpine releases older than 3.16 were exploitable in the researchers' lab and will get no fix.

No exploitation in the wild has been reported so far; the only confirmed exploitation is the researchers' own lab testing.

## Fixed versions

| Alpine branch | Fixed `openssh` package |
|---|---|
| edge | 10.6_p2-r0 |
| 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 |

Upstream, the fix is **OpenSSH 10.6p2**. Other musl-based distributions and firmware vendors need to ship that release or a backport.

## What to do now

1. **Check exposure** on each Alpine host or container running sshd (as root):

   ```
   sshd -T | grep -i -E 'passwordauthentication|usepam'
   ```

   If password authentication is off, or PAM is on, you are not exposed.

2. **Update and restart:**

   ```
   apk upgrade -U -a
   rc-service sshd restart
   ```

   Then rebuild and redeploy any container image whose `openssh` package is older than the version in the table above. Updating a running container without rebuilding the image will not survive a redeploy.

3. **If you can't patch yet**, set `PasswordAuthentication no` in `sshd_config` and restart sshd — after confirming key-based logins work, so you don't lock yourself out. On Alpine releases before 3.16 this is the only fix.

4. **Look for compromise:** search `/var/log/messages` for `Accepted password` entries for accounts that have no password. The researchers say any match should be treated as a compromised system.

**Who should care most:** anyone with Alpine-based VMs from the official cloud images, homegrown SSH-enabled containers, bastion or Git-over-SSH containers built on Alpine, and embedded devices that ship OpenSSH on musl. If your SSH servers already require keys only, this one passes you by — but it is a good reason to make that the rule everywhere.


## Sources

1. [OX Security (via Security Boulevard) — sshole (CVE-2026-123158): OpenSSH password bypass on Alpine Linux](https://securityboulevard.com/2026/11/sshole-cve-2026-123158-openssh-password-bypass-on-alpine-linux/)
2. [Cycode — sshole (CVE-2026-123158): OpenSSH password bypass on Alpine Linux](https://cycode.com/blog/sshole-cve-2026-123158-openssh-alpine-linux-vulnerability/)
3. [administrator.de — Kritische OpenSSH-Lücke (*sshole): Root-Zugriff mit beliebigem Passwort](https://administrator.de/info/openssh-sicherheitsluecke-ssh-zugriff-musl-libc-679405.html)
4. [Tech Insider — OpenSSH musl password bypass: CVE-2026-123158](https://tech-insider.org/openssh-musl-password-bypass-cve-2026-123158-alpine-linux-2026/)