# sshole (CVE-2026-123158): check your network

> An OpenSSH password bypass on musl Linux without PAM, such as Alpine. Who is affected, a 10-minute check for admins, the fix, and what monitoring can see.

Source page: https://netsenx.com/en/blog/2026-11-06_sshole-cve-2026-123158 · NetSenX Team · 2026-11-06

CVE-2026-123158, nicknamed "sshole" (also written sshhole), lets an attacker log in over SSH with a very long password on Linux systems where OpenSSH's sshd is built against musl libc without PAM, Alpine Linux being the best-known example. It is fixed in OpenSSH 10.6p2, published on 5 November 2026, and turning off password authentication closes it until you can upgrade. Most mainstream server distributions use glibc and PAM and sit outside the affected configuration; the risk is concentrated in Alpine hosts, containers built on Alpine that run sshd, and embedded Linux images.

## What is affected, and what is not

The CVE record describes it this way: sshd in OpenSSH before 10.6p2, on Linux, when musl libc is used without PAM, lacks a workaround for a password authentication bypass, and for some account configurations any password between 256 and 1,024 characters succeeds. The record scores it 8.1 (High) under CVSS 3.1.

The mechanism, as Alpine and several security researchers describe it: without PAM, sshd checks a password by calling the C library's `crypt()` and comparing the result with the account's entry in `/etc/shadow`. For an over-long input, musl's `crypt()` fails and returns the string `*`. Accounts that are not meant to log in with a password often have exactly `*` as their shadow entry, so the failure value matches and sshd accepts the login. An account with a real password hash is not opened this way: the failure value does not match the hash.

- **In the affected configuration:** OpenSSH older than 10.6p2, on musl libc, without PAM, with password authentication enabled, and with at least one account whose shadow entry is a bare `*`. Alpine's default OpenSSH build has no PAM. Researchers name key-only users and the default user of Alpine cloud images among the exposed accounts; root also has `*` by default on Alpine, but the default `PermitRootLogin prohibit-password` refuses a password login for root.
- **Outside it, per the CVE record:** glibc-based distributions and sshd builds that use PAM. Dropbear, the SSH server OpenWrt ships by default, is a different program from OpenSSH and is not the product named in the record; an OpenWrt device is only in scope if OpenSSH's server was installed on it.
- **Exploitation:** proof-of-concept code is public. The threat-intelligence company Previdian reports that its sensors observed exploitation attempts; as of 6 November 2026 other reports, such as Safe Security's, said in-the-wild exploitation was not confirmed and CISA had not added the CVE to its Known Exploited Vulnerabilities catalog. Treat any affected host that accepts SSH passwords from the internet as urgent either way.

## A 10-minute check for admins

Scan only networks you own or are authorised to test.

### Step 1: find the SSH listeners

From a host inside the network, list everything that answers on port 22, with the software version it announces. Replace the example range with your own subnets:

```bash
nmap -p 22 --open -sV 192.0.2.0/24
```

Include container hosts and lab networks. An sshd inside a container may be published on another port, so also check the port mappings your container platform exposes.

### Step 2: check the OpenSSH version and the C library on each host

`ssh -V` prints the installed OpenSSH version. `ldd --version` prints `musl libc` on a musl system and the glibc version on a glibc one. On Alpine, `apk info -v | grep openssh` shows the exact package versions.

```bash
ssh -V
ldd --version 2>&1 | head -1
```

### Step 3: check whether password logins are on

As root, print the configuration sshd actually runs with. `passwordauthentication no` means this path is closed on that host.

```bash
sshd -T | grep -i passwordauthentication
```

### Step 4: list the accounts with a bare `*`

These are the accounts the bypass can open:

```bash
awk -F: '$2 == "*" { print $1 }' /etc/shadow
```

A host is exposed if all four line up: an affected OpenSSH version, musl, password authentication on, and at least one listed account that SSH allows to log in.

## The fix

1. **Upgrade OpenSSH to 10.6p2, or to your distribution's fixed package.** On Alpine, the published instruction is `apk upgrade -U -a`.
2. **Restart sshd.** The running daemon keeps the old code until it restarts; on Alpine, `rc-service sshd restart`.
3. **Until you can upgrade, set `PasswordAuthentication no`** in `sshd_config` and reload sshd. If your users already log in with keys, this changes nothing for them, and it is the stopgap the advisories recommend.
4. **Rebuild container images** that run sshd on an Alpine base, and redeploy them: patching the host does not patch the image.
5. **Review recent SSH logins** on affected hosts, especially successful password logins to accounts that normally use keys or never log in.

## What network monitoring can and cannot see

SSH is encrypted, so the password never crosses the network in readable form. A network sensor cannot see the password, cannot tell how long it was, and cannot tell you that this particular bug was used: that evidence is in the host's own logs.

What network monitoring does see is the behaviour around a compromise. NetSenX scores how each host behaves on the network, and flags scanning, lateral movement, command-and-control beaconing and unusual outbound data volume, on every plan, Free included. A host that suddenly accepts SSH sessions from sources it has never talked to, or an Alpine container that starts connecting to other internal hosts after a login, is the kind of change those detections exist for. Every alert says, in plain language, why it fired. Use it alongside the host-level checks above, not instead of them.

If you are not sure whether someone is already inside, [how to tell if someone is inside your network](/en/is-someone-inside-your-network) lists the signs and the free checks to run, [how to detect lateral movement and C2 beaconing](/en/detect-lateral-movement-c2-beaconing) maps what follows a login to MITRE ATT&CK, and [NDR vs EDR vs SIEM](/en/blog/2026-09-24_ndr-vs-edr-vs-siem) explains which tool sees what. The Free plan monitors up to 3 devices with no time limit; see [pricing](/en/pricing).

## FAQ

### What is sshole (CVE-2026-123158)?

A password authentication bypass in OpenSSH's sshd before 10.6p2 on Linux systems that use musl libc without PAM, such as Alpine Linux. For some accounts, any password between 256 and 1,024 characters is accepted. The CVE record scores it 8.1 (High) under CVSS 3.1.

### Is my Ubuntu, Debian or Red Hat server affected?

Not by this CVE in their standard builds: those distributions use glibc and build sshd with PAM, and the CVE record limits the issue to musl libc without PAM. Containers on such hosts can still be affected if they are built on Alpine and run sshd.

### How do I fix it?

Upgrade OpenSSH to 10.6p2 or your distribution's fixed package, then restart sshd. Until you can, set PasswordAuthentication no in sshd_config and reload sshd. Rebuild any Alpine-based container images that run sshd.

### Is CVE-2026-123158 being exploited?

Previdian reports that its sensors observed exploitation attempts. As of 6 November 2026 other sources said in-the-wild exploitation was not confirmed and the CVE was not in CISA's Known Exploited Vulnerabilities catalog. Proof-of-concept code is public, so patch without waiting.

### Can network monitoring detect this attack?

Not the login itself: SSH is encrypted, so no network tool sees the password or its length. Network monitoring can show what happens around it, such as SSH sessions from unfamiliar sources, scanning or lateral movement from a host after a login. NetSenX flags scanning and lateral movement on every plan.

## Sources

All accessed on 6 November 2026.

- [CVE-2026-123158, CVE record (cvelistV5)](https://raw.githubusercontent.com/CVEProject/cvelistV5/main/cves/2026/123xxx/CVE-2026-123158.json) — description, affected versions, CVSS 3.1 score 8.1, published 5 November 2026
- [Alpine Linux — OpenSSH password authentication bypass](https://alpinelinux.org/posts/2026-11-05-openssh-password-authentication-bypass/) — the distribution advisory
- [OpenSSH release notes, 10.6p2](https://www.openssh.org/releasenotes.html#10.6p2)
- [OX Security — OpenSSH password authentication bypass on Alpine Linux](https://www.ox.security/blog/openssh-authentication-bypass-cve-2026-123158/) — mechanism and affected accounts
- [Previdian — CVE-2026-123158 exploitation attempts observed](https://previdian.com/CVE-2026-123158)
- [Safe Security — SSHole: high-severity OpenSSH vulnerability](https://safe.security/resources/blog/sshole-high-severity-openssh-vulnerability-turns-disabled-passwords-into-unauthorized-access/) — exploitation status as of 6 November 2026

---

*Written by the NetSenX Team at TriStiX S.L. This article is general information based on the public sources above as of 6 November 2026; check your distribution's advisory for the package versions that apply to you. Questions: [info@netsenx.com](mailto:info@netsenx.com).*