sshole: the OpenSSH flaw on Alpine and what to do
sshole (CVE-2026-123158) allows passwordless SSH into certain accounts on Alpine and other musl systems. Who it affects, how to fix it and what to check.
An OpenSSH flaw lets someone log in to certain accounts without knowing the password on Alpine Linux and other musl systems. It affects few systems, but those need to update now. Public status as of November 6, 2026.
What happened
It's tracked as CVE-2026-123158. It has a CVSS of 8.1 (high), assigned by MITRE; NIST hasn't published its own assessment yet. It was reported by Özgün Kültekin of Wakefield, and OpenSSH 10.6p2 fixed it on November 5.
Damien Miller of OpenSSH urged immediate action on affected systems. The project considers the root cause to lie outside OpenSSH, but it added the defense in `sshd` because that's where it can be exploited.
It isn't one of OpenAI's 948 flaws. That study, on the Linux kernel, also came out this week, and it's a separate story: we cover it in OpenAI and the 948 Linux kernel flaws.
How it works. Many accounts with no usable password, such as key-only ones, have a `` in `/etc/shadow`. According to the Alpine advisory and the write-up by its discoverer, on systems with the musl library an overly long password makes the hashing function return a `` as well. The two markers match and `sshd` accepts the login.
Who it affects
All of these conditions must hold, according to Alpine:
- OpenSSH on musl without PAM. Alpine's `openssh-server` package ships that way.
- `PasswordAuthentication` enabled, which is the default.
- An account with `*` as its password.
- Another local account with a real password (a `$5$` or `$6$` hash).
Who's out of scope. Linux with glibc, such as Debian, Ubuntu or Fedora; systems using PAM for passwords; and non-Linux systems, according to Miller. Alpine adds machines with `PasswordAuthentication no`, containers that don't run `sshd`, accounts locked with `!` and systems where no account has a `$` hash. On Alpine, `openssh-server-pam` is only out of scope with `UsePAM yes`: with `UsePAM no` it's affected.
Where to look. Besides Alpine, the discoverer mentions OpenWrt, Buildroot, Yocto and many Docker images. An image only matters if the container runs `sshd` set up that way.
Two cases worth pinning down:
- Root. Alpine ships root with `*`, but the default `PermitRootLogin` value blocks that password login. The risk comes from another account that can become root, for example through `doas`.
- Alpine cloud images. The official tiny-cloud images (qcow2, VHD and AMI) from 3.18.11 through 3.24.3 ship an `alpine` user with passwordless `doas`. The discoverer mentions the AWS and Azure ones. Alpine makes clear they're safe on first boot and become exploitable once a password is added to any account. Images set up with cloud-init aren't affected, because it writes `PasswordAuthentication no`.
Is it being attacked already?
Attempts have been recorded, and no real-world compromise has been independently confirmed:
- Previdian saw the first attempt about 8 hours after the CVE was published. Its page shows 5 attempts from 3 addresses, and warns that this doesn't prove they succeeded.
- Help Net Security, citing Previdian, reports 8 attempts from a single address and root access on a honeypot. The figures don't match, possibly because of when each was read.
- Safe Security and SOC Prime state that as of November 6, real-world exploitation hasn't been established.
- When we checked the CISA catalog on November 6, the flaw wasn't listed.
Public proofs of concept exist. Previdian warns they're unverified and may contain malware, so don't run them. With exploits in the open, the sensible course is to act as if attacks are already real.
Miller used the announcement to argue that long embargoes now favor attackers, since AI agents have rediscovered bugs within hours. Kültekin says swarms of AI agents were used in the search, without detailing their role.
What to do
- Identify where OpenSSH runs on musl: Alpine servers, containers with `sshd`, network gear and other devices.
- Update and restart `sshd`. Alpine warns that updating the package doesn't replace the process already running.
- Rebuild container images that include `openssh-server`, as SOC Prime recommends.
- If you can't update, set `PasswordAuthentication no`, after confirming key login works and with your session still open.
- Check the logs. Look in `/var/log/messages` for "Accepted password for" on passwordless accounts, `doas` use, new users and changes to `authorized_keys`. If you can't rule out a login, treat the machine as compromised.
Fixed versions on 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 |
Point releases 3.21.10, 3.22.8, 3.23.8 and 3.24.4 already include the fixed package. Source: the Alpine advisory, which notes that 3.16 through 3.21 are no longer supported; 3.21 lost support on November 1, 2026. Check the package version rather than the SSH banner, because distributions often backport fixes without changing the visible number, as SOC Prime warns.
What we don't know
- How many machines are exposed: the sources we reviewed give no figure.
- Whether the recorded attempts compromised any real system.
Frequently asked questions
Did OpenAI find it? No. It was reported by Özgün Kültekin of Wakefield and isn't one of the 948 kernel flaws OpenAI announced.
Is my Ubuntu or Debian server exposed? According to what's been published, not through this path, because they use glibc. It's still worth reviewing SSH and keeping it updated.
Are SSH keys enough? Yes, if `PasswordAuthentication` is really disabled. Check your configuration's `Match` rules too.
Is updating the package enough? No. You need to restart `sshd` and rebuild the container images that include it.
Sources
- OpenSSH, 10.6p2 release notes (November 5, 2026).
- Damien Miller, announcement on openssh-unix-dev (November 5, 2026).
- OpenSSH, fix commit (November 4, 2026).
- Alpine Linux, openssh-server advisory (November 5, 2026).
- Özgün Kültekin, sshole (November 2026).
- NVD, CVE-2026-123158.
- CISA, Known Exploited Vulnerabilities Catalog, CSV file (checked November 6, 2026).
- Previdian, CVE-2026-123158 (November 6, 2026).
- Help Net Security, Sinisa Markovic, on sshole (November 6, 2026).
- Safe Security, on SSHole (November 6, 2026).
- SOC Prime, on CVE-2026-123158 (November 6, 2026).
Follow the series
- OpenAI and the 948 Linux kernel flaws
- Part 1: Server security in the AI era
- Part 2: the kernel flaw that turned PHP2Shell into full control
Contact
If you need to review SSH access or how your organization's servers are kept up to date, ITLab can help. Contact us.
Do you need someone to take care of your technology?
Tell us what you need to organize, protect or solve. The first conversation has no cost: we assess whether our model fits you and what the next steps would be.
Let's talk about your business