OpenSSH vulnerability *sshole CVE-2026-123158: when * equals * on musl without PAM
On November 5, 2026, OpenSSH shipped 10.6p2 with a critical fix. On some musl Linux systems without PAM, accounts whose password field is * (meant to reject every password) can accept an oversized password. Researcher Özgün Kültekin (Wakefield) documents the scenario as *sshole (CVE-2026-123158 / GHSA-4fcc-vm97-gx3x).
Here’s who is affected, an educational schematic (not an attack procedure), the checklist and FAQs.
OpenSSH vulnerability: affected or safe?
| Environment | Status | Action |
|---|---|---|
| Alpine Linux (sshd without PAM, default) | Affected if PasswordAuthentication on + account with * | apk upgrade openssh → 10.6p2+ |
| Alpine AWS / Azure images (alpine + doas) | High risk if sshd is reachable | Update; disable password auth |
| OpenWrt / Buildroot / Yocto (musl) | Affected under the same conditions | OpenSSH 10.6p2 / vendor fix |
| Debian / Ubuntu / Fedora (glibc + PAM) | Not affected per public advisories | Nothing urgent for this flaw |
| sshd with UsePAM yes | Outside the described scenario | Still patch per your distro |
| PasswordAuthentication no | Immediate mitigation | Restart sshd after the change |
In short: this OpenSSH vulnerability does not hit typical Debian, Ubuntu or Fedora (glibc + PAM). It mainly concerns Alpine, OpenWrt, Buildroot, Yocto — and Alpine cloud images where the alpine account has a * and passwordless doas.
Educational schematic: why * can equal *
Fake names only. No attack script, no commands to run against a live system.
Password comparison (simplified schematic — fictional alice / deploy accounts)
OKaccount “alice” stored hash = $6$salt$… (real hash)
typed password → crypt() → $6$salt$… → match? depends on the right password
WARNaccount “deploy” field = * (password logins disabled)
normal password → crypt() → something other than * → denied
BADsame “deploy” account, VERY long password (schematic 257–1024 chars)
on musl, crypt() fails and returns * → * compared to * → accepted (bug)
How to read this mockup
- 1A real hash ($6$…) only matches the right password.
- 2A * field should reject every password: it is not a usable hash.
- 3On musl, an oversized password makes crypt() fail, which then returns *.
- 4OpenSSH (without PAM) compared that * to the stored * → false match. 10.6p2 fixes that path.
OpenSSH considers the root cause outside sshd, but the bypass was exploitable via sshd; the fix avoids the dangerous comparison. Typical public conditions: musl, PAM disabled, SSH password auth enabled, at least one account with *, and another account with a real hash (for the historical timing salt).
Action checklist for today
Do this in order
- ☐ Inventory: do you have Alpine / OpenWrt / Alpine cloud images / Buildroot-Yocto appliances with reachable sshd?
- ☐ Patch: OpenSSH 10.6p2 or newer (
apk upgrade opensshon Alpine). - ☐ Mitigate: if you cannot patch yet →
PasswordAuthentication nothen restart sshd (SSH keys only). - ☐ * accounts: find root / deploy / alpine with a
*or!field in shadow; confirm password auth is not required. - ☐ Logs: look for “Accepted password” lines for accounts that should not accept passwords (per the researcher’s public guidance).
- ☐ Exposure: sshd should not be open to the whole internet without controls (firewall, allowlist, bastion).
- ☐ Follow-up: automated 24/7 monitoring with on-call technician response helps spot abnormal SSH logins afterward.
Frequently asked questions
Q1. Is my Ubuntu VPS affected?
Public advisories put glibc + PAM (typical Debian/Ubuntu/Fedora) outside this scenario. Still patch per your provider, but the urgent priority is musl without PAM.
Q2. Alpine Docker on my laptop?
Practical risk mainly needs an exposed sshd. An Alpine image without a listening sshd does not open this door. Check containers / VMs that actually listen on 22.
Q3. Is PasswordAuthentication no enough?
As a temporary mitigation, yes per OpenSSH / the researcher. The 10.6p2 fix remains the real repair.
Q4. Is there a single official CVSS?
Follow GHSA-4fcc-vm97-gx3x and OpenSSH / Alpine advisories. Don’t trust an invented number.
SSH auth flaws are a reminder that the “small server” surface matters as much as the workstation — as we’ve seen with other exposures in our articles on cybersecurity services and server management.
How NeoTech can help
We inventory your musl / Alpine hosts, apply OpenSSH 10.6p2, disable password auth if needed, and review login logs. Our automated 24/7 monitoring with on-call technician response flags unusual SSH authentications. For a full picture, see our cybersecurity services.
Book your free cyber check
In 30 minutes, we check together whether you have Alpine/musl hosts with sshd, which OpenSSH version is running, and whether password auth is still open.
Call us at 438-476-2322 or email info@neotechcloudsolutions.com.
Our office: 2572 boul. Daniel-Johnson, office 237, Laval.
Sources
- oss-security — “sshole”: OpenSSH + musl password auth bypass, Nov. 5, 2026
- OpenSSH — 10.6p2 release notes
- BleepingComputer — OpenSSH flaw / password-disabled accounts, Nov. 5, 2026
- GitHub Advisory GHSA-4fcc-vm97-gx3x
- sshhole.com — researcher page (Özgün Kültekin / Wakefield)
Photo: Manuel Geissinger, Pexels (Pexels licence).