OpenSSH "sshole" (CVE-2026-123158): what happened and what to do today

#What happened, in three lines

1. On November 5, 2026 a flaw nicknamed “sshole” went public. It lets an attacker log into some Linux servers over SSH without knowing the password. It is tracked as CVE-2026-123158, with a CVSS score of 8.1 (High).
2. It only affects servers that use musl libc (Alpine Linux is the best known) running OpenSSH without PAM with password login enabled. Ubuntu, Debian, Red Hat and most servers are not affected.
3. A fix is out: OpenSSH 10.6p2, plus fixed Alpine packages for releases 3.16 through edge. Update and restart sshd. If you cannot update yet, turn off password login.

alpinelinux.org · Security advisory

#Am I affected? Who is and who is not

All of these have to be true at the same time. If even one is missing, that server is not affected.

Altamar · Does sshole affect you?

One important detail: Alpine’s root account has shipped with a * field since about release 3.16, but OpenSSH’s default setting (PermitRootLogin prohibit-password) protects it. The real risk is other accounts without a password that can become root, for example through doas. Alpine explains this in its advisory.

#How the bug works (the simple version)

When OpenSSH checks a password without PAM, it hashes what you typed and compares the result with what the system has stored. For accounts with no password, what is stored is a single asterisk: *.

The trouble is that musl, the C library Alpine uses, also returns * when it is handed a password that is too long (more than 256 bytes), as an error signal. So the server compares * with *, sees a match, and lets the attacker in. Neither OpenSSH nor musl has a serious bug on its own: the failure is in how they fit together.

This is not a cryptographic weakness or a memory-corruption vulnerability. It is an authentication logic failure caused by the interaction between two components that interpret the same value differently.

OpenSSH puts it this way in its release notes:

We consider the root cause of this bug to be outside sshd, but it is exploitable via sshd and can be avoided there.

openssh.org · Release Notes

The bug was reported by Özgün Kültekin of Wakefield, according to OpenSSH and Alpine. OX Security says he found it by building sshd in every combination of glibc, musl, PAM and no PAM, then throwing “roughly 17,600 deliberately unusual login attempts at each build”.

#Timeline

Altamar · Timeline

• November 5, 2026: public disclosure on the oss-security list, the OpenSSH 10.6p2 release, and Alpine’s advisory with fixed packages. The CVE-2026-123158 record was published the same day, with CVSS 8.1 (vector AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H).
• That day, The Hacker News wrote: “No attacks using the flaw have been reported.”
• November 6: threat intelligence firm Previdian told Help Net Security it saw a first exploitation attempt less than nine hours after the CVE was published and got root access on its own honeypot.

Our first observed attempt arrived less than nine hours after CVE publication, and we’ve confirmed successful root access on a Previdian honeypot running real Alpine Linux and OpenSSH

helpnetsecurity.com

What is disputed: the exploitation report comes from one company, on its own honeypot, with eight attempts counted from a single IP address in Japan (Help Net Security, The Hacker News). Help Net Security notes that CISA has not added it to its Known Exploited Vulnerabilities (KEV) catalog. We found no independent confirmation. Our advice is to treat it as exploitable: the attack is simple and proof-of-concept code is already circulating, which Previdian warns is unverified and could contain malware.

#What to do today

1. Take inventory. List every server, VPS and container with an SSH port open. Include the “forgotten” ones: routers, gateways, test servers.
2. Check the operating system. cat /etc/os-release. If it says Alpine, keep going. If it is Ubuntu, Debian or RHEL, that machine is not affected by this flaw (but it is still a good moment to update).
3. Check the OpenSSH version. ssh -V shows the installed version. On Alpine, do not compare against 10.6p2: the stable branches carry the fix as a patch on their own version. Compare with the table below.
4. Update. On Alpine: apk upgrade -U -a.
5. Restart sshd. rc-service sshd restart. Updating the package does not restart the daemon that is already running.
6. If you cannot update today, turn off password login. Set PasswordAuthentication no in the sshd configuration and restart. First make sure your key login works, and keep your current session open until you have tested a new one. Check with sshd -T | grep -i passwordauthentication, which should print passwordauthentication no.
7. Check your container and cloud images. If your Alpine containers run sshd inside, rebuild them from a fixed base image. If you use Alpine tiny-cloud images older than 3.21.10, 3.22.8, 3.23.8 or 3.24.4, update openssh on every running instance.
8. Look for signs of a break-in. In /var/log/messages, search for sshd lines reading Accepted password for on accounts that have no password (alpine, root or key-only users). Review doas use, recently created users and authorized_keys files.

Source: Alpine’s advisory and its security database (secdb), checked on November 7, 2026. Branch 3.15 and older have no published fix: if you run something that old, the way out is to migrate or turn off password login.

If you cannot rule out a login, treat the machine as compromised.

#Lessons for any business

• Patching fast matters. Between disclosure and the first reported attack attempt there were hours, not weeks. Have an owner and a process for applying security patches the same day.
• You cannot protect what you do not know you have. Many businesses do not know how many servers, VPSs or containers they run, or on what system. A simple inventory (what, where, who maintains it) comes first.
• Old images are a quiet risk. A container image nobody rebuilds keeps its bugs even after the system “has been fixed”.
• Fewer open doors. If a server does not need SSH open to the internet, close it or put it behind a VPN. And use keys instead of passwords.
• Watch the logs. Knowing who logged in, when and how is what lets you answer “were we attacked?”.

#How Altamar can help

If you are not sure which servers you run, or whether any of them use Alpine with SSH open, we can help you take that inventory, apply the fix, and leave a process in place for next time. Book a call with one of our engineers.

#References

All checked on November 7, 2026.

• OpenSSH, 10.6p2 release notes (Nov 5, 2026): openssh.org/releasenotes.html
• openssh-unix-announce post (Nov 5, 2026): lists.mindrot.org
• Jan Schaumann, oss-security, “sshole”: password authentication bypass (Nov 5, 2026): openwall.com
• CVE-2026-123158 record: cve.org and NVD
• Alpine Linux, security advisory (Nov 5, 2026): alpinelinux.org
• Alpine Linux, security tracker: security.alpinelinux.org and secdb
• OX Security, technical analysis (Nov 5, 2026): ox.security
• BleepingComputer (Nov 5, 2026): bleepingcomputer.com
• The Hacker News, “OpenSSH Issues Emergency Fix…” (Nov 5, 2026): thehackernews.com
• The Hacker News, “Hackers Target OpenSSH SSHole Flaw Within Hours of Disclosure…” (Nov 6, 2026): thehackernews.com
• Help Net Security (Nov 6, 2026): helpnetsecurity.com
• GIGAZINE (Nov 6, 2026, in Japanese): gigazine.net