---
title: "SSHole: OpenSSH Password Bypass on Alpine and musl Linux"
url: https://erroneo.us/security/briefs/sshole-openssh-musl-password-bypass-cve-2026-123158/
description: "Any 257-1024 byte password logs into '*' accounts on OpenSSH without PAM on musl (Alpine). Fixed in 10.6p2 and Alpine packages. Check exposure now."
type: security-brief
section: "Security Digest"
date_published: 2026-11-05
date_modified: 2026-11-06
publisher: erroneo.us
author: erroneo.us Security Desk
verdict: "Check exposure"
cves: ["CVE-2026-123158"]
severity: "high"
exploited: "public-poc"
kev: false
license: All rights reserved. Quote with attribution and a link.
---

# SSHole: OpenSSH Password Bypass on Alpine and musl Linux

**Verdict: Check exposure.** Most SSH servers run glibc and are not affected, but if you run OpenSSH on Alpine or another musl system with password logins enabled, this is a one-connection login with public details, so patch or turn off password authentication today.

- **Who must act:** Anyone running openssh-server on Alpine Linux (including official AWS and Azure tiny-cloud images) or another musl-based system such as Buildroot, Yocto or OpenWrt with OpenSSH installed, without PAM and with PasswordAuthentication enabled.
- **Who can relax:** Debian, Ubuntu, Fedora, RHEL and other glibc systems, sshd that authenticates through PAM, Dropbear, servers with PasswordAuthentication no, and Alpine containers that do not run sshd are not affected.
- **Affected:** OpenSSH portable before 10.6p2 on Linux with musl libc and PAM disabled; Alpine Linux edge and 3.16 through 3.24 before the fixed openssh packages; Alpine tiny-cloud images 3.18.11 through 3.24.3 (alpine user with '*' password and passwordless doas)
- **Fixed:** OpenSSH 10.6p2; Alpine edge: openssh 10.6_p2-r0; Alpine 3.24: 10.3_p1-r2; Alpine 3.23: 10.2_p1-r1; Alpine 3.22: 10.0_p1-r11; Alpine 3.21: 9.9_p2-r1; Alpine 3.20: 9.7_p1-r6; Alpine 3.19: 9.6_p1-r3; Alpine 3.18: 9.3_p2-r4; Alpine 3.17: 9.1_p1-r7; Alpine 3.16: 9.0_p1-r6; Alpine point releases 3.21.10, 3.22.8, 3.23.8, 3.24.4
- **CVEs:** CVE-2026-123158
- **CISA KEV:** no · **Exploitation:** Public proof-of-concept

## What to do

1. On Alpine, run apk upgrade -U -a and then rc-service sshd restart; upgrading the package does not replace the running daemon.
2. If you cannot patch right now, set PasswordAuthentication no in a file under /etc/ssh/sshd_config.d/, validate with sshd -t, and restart sshd, keeping a key-based session open while you do it.
3. Find every musl-based host and container that runs sshd, including Alpine cloud instances, appliances built with Buildroot or Yocto, and OpenWrt devices where OpenSSH replaced Dropbear.
4. Rebuild Alpine-based images that ship sshd and redeploy cloud instances from fixed point releases (3.21.10, 3.22.8, 3.23.8, 3.24.4 or later).
5. If any host was reachable with password logins enabled, review its auth logs before you consider it clean, and treat it as compromised if you cannot rule out a login.

### How to check if you are affected

- Check the version: apk version openssh (Alpine) or ssh -V, and compare with the fixed packages above.
- Check the running config: sshd -T | grep -Ei 'passwordauthentication|usepam'. You are exposed only if password authentication is yes and PAM is not used.
- List accounts with '*' and accounts with real hashes: awk -F: '$2=="*"{print $1}' /etc/shadow and awk -F: '$2 ~ /^\$[56]\$/{print $1}' /etc/shadow. Exposure needs both.
- Search for password logins to accounts that have no password: grep 'Accepted password for' /var/log/messages, then review doas usage, new users and authorized_keys files on any hit.

## What happened

On November 5, 2026, OpenSSH released [portable OpenSSH 10.6p2](https://www.openssh.org/releasenotes.html) to block a password authentication bypass that is "exploitable through sshd(8)" on some Linux systems built and run without PAM. Alpine Linux published an [advisory and fixed packages](https://alpinelinux.org/posts/2026-11-05-openssh-password-authentication-bypass/) for every branch from 3.16 to edge on the same day. Researcher Özgün Kültekin of Wakefield, who reported it, calls the bug [SSHole](https://sshhole.com/). It is tracked as [CVE-2026-123158](https://www.cve.org/CVERecord?id=CVE-2026-123158), CVSS 3.1 score 8.1 from the CNA.

The cause is two decisions that each made sense in isolation. Without PAM, sshd checks a password by running it through `crypt()` and comparing the result with the stored hash. Since a 2016 fix for username enumeration (CVE-2016-6210), sshd borrows another account's salt when an account has no usable hash, so that every login takes the same time. musl libc's `crypt()` returns the string `*` on failure, and its SHA-crypt code fails for keys longer than 256 bytes. `*` is also the conventional password field for accounts that should never accept a password. If you send an oversized password to such an account, the hash comes back as `*`, it matches the stored `*`, and the login succeeds. Alpine's advisory says it "takes one connection, works every time, and needs no retries."

## Who is affected

All of these must be true, according to Alpine:

- sshd runs on musl. Alpine's `openssh-server` package is built without PAM, and `openssh-server-pam` is affected only with `UsePAM no`.
- `PasswordAuthentication` is `yes`, which is the OpenSSH default.
- The attacker knows the name of an account whose password field is `*`. That includes key-only users, directory-service users and root on Alpine since about 3.16. Root is still protected by the default `PermitRootLogin prohibit-password`.
- At least one other local account has a `$5$` or `$6$` hash.

Alpine says the official tiny-cloud images from 3.18.11 to 3.24.3 ship an `alpine` user with a `*` password and passwordless `doas`. They are safe on first boot but become exploitable as soon as any account on the machine gets a real password, and the result is effectively root. Kültekin's write-up also names OpenWrt, Buildroot and Yocto. OpenWrt uses Dropbear by default, which is not affected, so it matters there only if you installed OpenSSH. glibc distributions (Debian, Ubuntu, Fedora and RHEL), PAM-based setups and OpenBSD are not affected.

## Do you really need to act?

**Only if you match the list above, and then today.** Most internet-facing SSH runs on glibc distributions and is not affected. Alpine containers that do not run sshd, which is the usual case, are not affected either. But for the hosts that do match, there is nothing to brute-force. The attacker needs only a reachable port and an account name, and Alpine's own example accounts (`alpine` and key-only service users) are predictable. As of November 6 no vendor reported exploitation in the wild. However, the details are public, the CVE record links reproduction labs, and CISA's SSVC entry marks exploitation as "poc." Researchers quoted by SecurityWeek expect brute-force tools to add the trick within days.

## What to do now

1. Patch and restart: `apk upgrade -U -a && rc-service sshd restart`. The fixed Alpine packages range from `openssh 10.6_p2-r0` on edge to `9.0_p1-r6` on 3.16. If you build OpenSSH yourself, use 10.6p2.
2. If you cannot patch yet, turn off password logins. Keep an existing key-based session open, add `PasswordAuthentication no` in `/etc/ssh/sshd_config.d/`, run `sshd -t`, then restart sshd. OpenSSH developer Damien Miller told affected users to do this "IMMEDIATELY."
3. Check the effective config with `sshd -T | grep -Ei 'passwordauthentication|usepam'`, not just the file. Drop-ins and match blocks can override it.
4. Look beyond servers. Check appliances and embedded devices built with Buildroot or Yocto, OpenWrt routers with OpenSSH, and any Alpine-based image that bundles sshd for CI, dev containers or Git hosting. Rebuild those images.
5. Redeploy cloud instances from fixed point releases (3.21.10, 3.22.8, 3.23.8, 3.24.4) or patch them in place.

## How to tell if you were hit

Search `/var/log/messages` (Alpine) for `Accepted password for` on accounts that have no password, such as `alpine`, root or key-only users. Compare them against `awk -F: '$2=="*"{print $1}' /etc/shadow`. Exploit attempts use passwords of 257 to 1,024 bytes, but sshd does not log password contents, so the successful login line is the signal. On any hit, review `doas` usage, new accounts, changed files and `~/.ssh/authorized_keys`. Alpine's advice is to treat the machine as compromised if you cannot rule out a login.

## Timeline

- Aug 29, 2012 — musl adds SHA-512 crypt with a 256-byte key limit, after earlier changing `crypt()` to return `*` on failure.
- Jul 15, 2016 — OpenSSH adds salt borrowing to fix username enumeration (CVE-2016-6210).
- Nov 5, 2026 — OpenSSH 10.6p2 and Alpine fixed packages released, and CVE-2026-123158 published.
- Nov 6, 2026 — No exploitation in the wild reported as of this date.

## Sources

1. [OpenSSH — Release notes, OpenSSH 10.6p2](https://www.openssh.org/releasenotes.html)
2. [Alpine Linux — openssh-server password authentication bypass](https://alpinelinux.org/posts/2026-11-05-openssh-password-authentication-bypass/)
3. [CVE.org — CVE-2026-123158](https://www.cve.org/CVERecord?id=CVE-2026-123158)
4. [Özgün Kültekin — SSHole write-up](https://sshhole.com/)
5. [BleepingComputer — OpenSSH flaw lets attackers log into password-disabled Linux accounts](https://www.bleepingcomputer.com/news/security/openssh-flaw-lets-attackers-log-into-password-disabled-linux-accounts/)
6. [SecurityWeek — OpenSSH Rushes Patches for 'SSHole' Authentication Bypass](https://www.securityweek.com/openssh-rushes-patches-for-sshole-authentication-bypass/)
7. [The Hacker News — OpenSSH Issues Emergency Fix for Flaw Letting Long Passwords Bypass SSH Auth on Alpine Linux](https://thehackernews.com/2026/11/openssh-issues-emergency-fix-for-flaw.html)

---
Source page: https://erroneo.us/security/briefs/sshole-openssh-musl-password-bypass-cve-2026-123158/ · Security Digest: https://erroneo.us/security/ · More: https://erroneo.us/llms.txt