---
title: "Detecting the OpenSSH Password Bypass (CVE-2026-123158) on Alpine and musl Linux"
url: "https://www.armorcode.com/blog/cve-2026-123158-openssh-password-bypass-alpine-musl"
markdown_url: "https://www.armorcode.com/blog/cve-2026-123158-openssh-password-bypass-alpine-musl.md"
llm_canonical: "https://www.armorcode.com/blog/cve-2026-123158-openssh-password-bypass-alpine-musl.md"
canonical_for_llm: true
entity_type: "Article"
primary_entity: "Detecting the OpenSSH Password Bypass (CVE-2026-123158) on Alpine and musl Linux"
citation_value: "Published on ArmorCode; canonical URL https://www.armorcode.com/blog/cve-2026-123158-openssh-password-bypass-alpine-musl."
last_updated: "2026-11-08T22:23:03-08:00"
---

<h1>Detecting the OpenSSH Password Bypass (CVE-2026-123158) on Alpine and musl Linux</h1>

<h2>Key Takeaways</h2>

- **What it is:** CVE-2026-123158, nicknamed *sshole, is an OpenSSH password authentication bypass rated CVSS 8.1 (High). A single long password lets an attacker log in to an account that has no password.
- **Who is affected:** Linux systems running sshd on musl libc without PAM, including Alpine’s default openssh-server, when password authentication is enabled and at least one other account has a hashed password.
- **How to fix it:** Update to OpenSSH 10.6p2 or your Alpine branch’s patched package, then restart sshd, because the upgrade does not replace the running daemon. If you cannot update, set PasswordAuthentication no
- **How to find your exposure:** Search by CVE ID in ArmorCode, using Anya or the “OpenSSH sshhole (Nov 2026)” view. 

<h2>What is CVE-2026-123158 (*sshhole)?</h2>

On November 5, 2026, the OpenSSH project released 10.6p2 to fix a password authentication bypass in sshd. Tracked as **CVE-2026-123158** and nicknamed ***sshole**, it lets a remote attacker log in to an account that has no password set, using one password between 257 and 1,024 bytes long. It needs a single connection and no retries. The CVE is rated **CVSS 8.1 (High)**, and the bug was reported by Özgün Kültekin of Wakefield.

It only affects Linux systems running sshd on **musl libc without PAM**. That includes Alpine Linux’s default openssh-server package, so Alpine-based hosts and images are the ones to check first.

<h2>How the OpenSSH password bypass works on musl</h2>

Without PAM, sshd verifies a password by hashing the attempt with crypt() and comparing the result to the account’s stored password field. Two behaviors collide:

- On musl, crypt() refuses SHA-256 and SHA-512 inputs longer than 256 bytes and returns the string * as an error value.
- Accounts with no password, which is normal for key-only users, store exactly * in the password field. For such accounts, sshd borrows the hash salt of another account.

The error value matches the stored value, so the login succeeds. The attacker needs the name of a passwordless account, and the machine needs at least one other account with a $5$ or $6$ password hash. One such user is enough to expose every passwordless account. The flaw is reported to date back about a decade, partly because OpenSSH is mainly tested on OpenBSD and glibc.

<h2>Who is affected by CVE-2026-123158?</h2>

A system is exposed when all of the following are true:

| **Condition** | **Detail** |
| --- | --- |
| musl libc, no PAM | Alpine openssh-server, or openssh-server-pam with UsePAM no. With UsePAM yes it is not affected. |
| Passwords allowed | PasswordAuthentication yes, which is the OpenSSH default |
| A passwordless account | Password field is *: key-only users, directory-service users, root in Alpine base images (reachable only if PermitRootLogin yes, or via another account that can use doas), and the alpine user in tiny-cloud images |
| A hashed password | At least one local account with a $5$ or $6$ hash |

**Not affected:** glibc distributions such as Debian, Ubuntu, RHEL and Fedora; SSH servers using PAM; containers that do not run sshd; systems with PasswordAuthentication no; and locked accounts (! in /etc/shadow). Alpine notes that official tiny-cloud images from 3.18.11 through 3.24.3 ship an alpine user with passwordless doas. They are safe on first boot but become exploitable once any $6$ hash exists, and an attacker can then escalate to root.

<h2>Fixed versions: OpenSSH 10.6p2 and Alpine packages</h2>

Upstream, the fix is OpenSSH **10.6p2**. Alpine has shipped fixed packages for every branch, including unsupported ones back to 3.16.

| **Alpine branch** | **Fixed openssh package** |
| --- | --- |
| edge | 10.6_p2-r0 |
| 3.24 | 10.3_p1-r2 (in 3.24.4) |
| 3.23 | 10.2_p1-r1 (in 3.23.8) |
| 3.22 | 10.0_p1-r11 (in 3.22.8) |
| 3.21 | 9.9_p2-r1 (in 3.21.10, now end of life) |

Upgrading the package does not replace the running daemon, so **restart** sshd afterwards.

<h2>How to detect CVE-2026-123158 with ArmorCode</h2>

<h3>1. Ask Anya</h3>

Start with Anya, ArmorCode’s AI security champion, where you can ask targeted questions such as:

- Am I impacted by CVE-2026-123158?
- Show me all applications, services, and workloads exposed to CVE-2026-123158.
- Am I vulnerable to the OpenSSH sshhole vulnerability (CVE-2026-123158)?

<h3>2. Findings Page</h3>

- Navigate to the Findings page to access the pre-configured saved view, “OpenSSH sshhole (Nov 2026)”. By consolidating results around the CVE ID, it unifies findings from all connected scanners into a single triage workflow. Prioritize remediation by sorting assets according to their criticality and internet exposure.

<h2>What to do right now</h2>

1. **Update and restart.** Run apk upgrade -U -a, then rc-service sshd restart. For images, rebuild from a patched base.
2. **If you cannot update,** set PasswordAuthentication no, restart sshd, and confirm with sshd -T | grep -i passwordauthentication. Test key login in a second session first.
3. **Confirm exposure on a host.** Check whether sshd links against musl (ldd $(which sshd) | grep musl), and review which accounts have * in /etc/shadow.
4. **Check for compromise.** Search /var/log/messages for Accepted password for an account that has no password, then review doas use, new users, files and authorized_keys. If you cannot rule out a login, treat the host as compromised.
5. **Restrict SSH access** with network controls until patched, and keep passwords disabled for key-only accounts.

<h2>References</h2>

- **Alpine Linux:** [Security advisory: openssh-server password authentication bypass](https://alpinelinux.org/posts/2026-11-05-openssh-password-authentication-bypass/)
- **OX Security:** [OpenSSH Password Authentication Bypass on Alpine Linux (*sshole)](https://www.ox.security/blog/openssh-authentication-bypass-cve-2026-123158/)
- **OpenSSH:** [10.6p2 release notes](https://www.openssh.com/releasenotes.html)