Menu
Breach Value Calculator

OpenSSH SSHole (CVE-2026-123158): Check Alpine Servers and Containers

SSHole (CVE-2026-123158) lets attackers log in to some Alpine and musl OpenSSH servers without a password. Who is affected, the fix, and what to check.

By CyphrQ.ai

Written with AI assistance and human editorial review. Every figure linked to its source.

Published 13 min read

AI-generated illustration: OpenSSH SSHole (CVE-2026-123158): Check Alpine Servers and Containers
AI-generated illustration

SSHole (CVE-2026-123158) lets an outsider log in over SSH to accounts that have no usable password (a * in /etc/shadow) on Linux systems using the musl C library without PAM, mainly Alpine. Fixes are in OpenSSH 10.6p2 and patched Alpine packages from 5 November 2026. CISA lists it as exploited. Update, restart sshd, check your logs.

Sources checked 10 November 2026.

If you run Alpine anywhere, on a server, a cloud instance or as the base of your container images, this post is for you. Most Alpine containers don't run an SSH server at all, and those aren't affected. The ones that do, and every Alpine machine that accepts SSH passwords, need attention this week.

This post answers four questions: am I affected, how do I check, what is the fix, and how do I tell whether someone got in first. Why the gap between disclosure and attack keeps shrinking is covered in our emergency patching plan. Other flaws under active attack are listed under exploited vulnerabilities.

What is OpenSSH SSHole (CVE-2026-123158)?

SSH is the standard way administrators log in to Linux machines remotely, and OpenSSH is the software most of them use. The part that accepts logins is called sshd.

OpenSSH's 10.6p2 release notes, dated 5 November 2026, describe "a critical security workaround that affects Linux systems that use the musl libc and PAM disabled." The fix is to "avoid password authentication bypass that is exploitable through sshd(8) that affects some Linux systems when built and run with PAM support disabled."

Two terms need a sentence each. A C library (libc) is the base layer of code almost every Linux program relies on; most distributions use one called glibc, while Alpine uses a smaller one called musl. PAM (Pluggable Authentication Modules) is the system many distributions use to check passwords; Alpine's standard SSH server package doesn't use it.

The Alpine security tracker explains the cause as a "misinterpretation of whether a string is intended to be a password hash." In plain terms, on these systems the password check can be fooled into accepting a login for an account that was never meant to have a password at all. OpenSSH adds that it considers "the root cause of this bug to be outside sshd," but it "can be avoided there," which is what 10.6p2 does.

OpenSSH and Alpine both credit the report to Özgün Kültekin of Wakefield, a company OpenSSH identifies as wakefield.co. The "SSHole" nickname comes from the researcher, according to Help Net Security. How the attack works is left out on purpose: the fix and the checks below don't depend on it.

Which systems are affected?

Alpine's advisory of 5 November is the clearest guide. A system is at risk when all of these hold:

  • It runs OpenSSH's sshd older than 10.6p2, on Linux, linked against musl.
  • PAM is not in use: either the standard openssh-server package, or openssh-server-pam with UsePAM no.
  • Password logins are allowed.
  • It has an account with no usable password (shown as * in /etc/shadow), plus at least one other local account with a standard SHA-256 or SHA-512 password hash (starting $5$ or $6$).

Accounts with no usable password are common, which is what makes this serious. Alpine lists root in its base images (exploitable only if PermitRootLogin yes is set, or another login account can reach root, for example through doas), key-only users created without a password, directory-service users, and the alpine user in official tiny-cloud images.

Affected Alpine releases are 3.21 to 3.24 and edge, plus the unsupported 3.16 to 3.20, per the same advisory. Belgium's national cyber security centre, the CCB, also names "exposed Alpine Linux and OpenWRT environments." For OpenWrt and other embedded builds, what matters is whether the device runs OpenSSH linked against musl, without PAM. Check before assuming either way.

Who is not affected?

Setup Status Source
Alpine containers that don't run sshd Not affected Alpine advisory
Password logins turned off Not affected Alpine advisory
openssh-server-pam with UsePAM yes Not affected Alpine advisory
Locked accounts (! in /etc/shadow) Not affected Alpine advisory
Red Hat products (glibc and PAM) Not affected Red Hat
Fedora, and glibc-based systems generally Not affected, per the researcher Help Net Security
Dropbear SSH server, OpenBSD Not affected, per the researcher Help Net Security

Red Hat's statement is direct: "Red Hat products are not affected by this vulnerability," because RHEL links OpenSSH against glibc and uses PAM by default.

Debian and Ubuntu haven't given a final verdict yet. On 10 November 2026, the Debian security tracker listed openssh in bookworm and trixie as "vulnerable" and fixed in forky and sid (10.6p2-1), with no reason given.

Ubuntu's CVE page listed every release as "Needs evaluation", with a note saying Ubuntu doesn't use musl libc by default, so it expects to be not affected, but musl is available in its archive. On those systems, take the security update when it arrives, and check for any OpenSSH you built against musl yourself.

Are attackers already using it?

Yes. On 9 November 2026, CISA added CVE-2026-123158 to its Known Exploited Vulnerabilities (KEV) catalogue, with a due date of 12 November. That deadline binds US federal civilian agencies. For everyone else, a three-day window is a plain signal of how urgently CISA rates the risk. The CCB advisory of 6 November also says it "is actively exploited in the wild."

Attacks started quickly. Threat intelligence firm Previdian's tracking page dates the CVE's publication to 5 November and its first observed exploitation attempt to 00:05 UTC on 6 November. By 10 November it had counted 22 attempts from 14 attacker addresses in 10 countries, seen by 4 of its sensors.

Help Net Security reported on 6 November that Previdian put the first attempt at under nine hours after CVE publication, and that it confirmed root access on a honeypot (a decoy machine set up to be attacked) running Alpine and OpenSSH. These are one vendor's sensors, so they show how fast attacks began, not how widespread they are.

What should I do today?

Work through these in order.

  1. List every Alpine system that runs sshd. Servers, cloud instances, appliances, and any container image whose build installs openssh-server. Search your Dockerfiles and image definitions for openssh.
  2. Check the installed version. On Alpine, apk info -v | grep openssh shows the package version. Compare it with the fixed versions in the table below.
  3. Check whether password logins are on. Run sshd -T | grep -i passwordauthentication as root. It prints the setting sshd is actually using.
  4. Update and restart. Alpine's advisory gives apk upgrade -U -a followed by rc-service sshd restart. The restart matters: upgrading the package does not restart a running sshd, so the old code keeps serving logins until you do.
  5. For containers, rebuild. Patching inside a running container is lost when it is replaced. Rebuild the image from a patched base, check the OpenSSH package version in the new image, and redeploy.
  6. Check for signs of a break-in (below), even after you patch.

Fixed Alpine package versions

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

Source: Alpine advisory, 5 November 2026. The rows for edge through 3.19 match the Alpine security tracker as read on 10 November 2026. For 3.19 the tracker also lists 9.7_p2-r5 as fixed, and it doesn't show 3.16 to 3.18. Alpine backports the fix into each branch's existing OpenSSH version, so the version number alone won't say 10.6p2. Check the full package release (the -r number).

Can't update yet? Turn off password logins

The interim fix is one line in the SSH server configuration: PasswordAuthentication no. Alpine's advisory recommends it if you can't upgrade straight away. Before you apply it:

  • Confirm key-based login works first, and keep your current session open while you test, as Alpine advises. Otherwise you can lock yourself out.
  • Restart or reload sshd, then rerun sshd -T to confirm the setting took effect.
  • Expect anyone who logs in with a password to be cut off. Give them keys first.
  • It is a stopgap. Install the patched package as soon as you can.

How do I tell if someone already got in?

Alpine's advisory gives the starting points:

  • Search /var/log/messages for "Accepted password for" on accounts that have no password, such as alpine, root or key-only users. A password login to an account that has no password is the clearest sign.
  • Review doas use, the Alpine tool for running commands as root.
  • Look for recently created users, changed files, and new entries in authorized_keys files. An attacker who gets in once will often add their own key so they can come back after you patch.

Alpine's advice is blunt: if you can't rule out a login, treat the machine as compromised. For a cloud instance or a container, that usually means rebuilding from a clean image and rotating any secrets it held, rather than cleaning it in place.

Going deeper: for security and IT teams

Identifiers and scoring. Sources differ on both the score and the weakness class:

Source CVSS v3.1 Vector CWE
cve.org (as listed by Red Hat) 8.1 AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H —
Red Hat 9.8 AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H CWE-303, Incorrect Implementation of Authentication Algorithm
CISA KEV — — CWE-394, Unexpected Status Code or Return Value
CCB (Belgium) 8.1 — —

Sources: Red Hat and the KEV entry, read 10 November 2026. Red Hat's page showed no NVD score that day.

The only difference between the two vectors is attack complexity. The high-complexity rating reflects the account and configuration conditions an attacker needs. On a stock tiny-cloud image those conditions can already hold, so I'd plan to the higher score. CISA's KEV entry names it "OpenBSD OpenSSH Unexpected Status Code or Return Value Vulnerability", sets "Known ransomware use" to Unknown, and marks forensic triage as required under BOD 26-04. CCB makes the same point in its own words: patching "does not remediate historic compromise." Weighing a KEV listing against a CVSS score in general is covered in our primer on the three vulnerability scores.

Mechanism. Without PAM, sshd checks a password itself, against the hash stored for the account. Per the Alpine tracker, the bypass comes from a "misinterpretation of whether a string is intended to be a password hash." A * in the shadow file means "no valid password"; under the conditions Alpine lists, the check can succeed against it anyway. OpenSSH places the root cause outside sshd, and describes 10.6p2 as a workaround inside it. My reading of those two statements has two consequences. First, the fix covers sshd only, so other software on the same systems that checks passwords without PAM deserves a review. Second, openssh-server-pam with UsePAM yes hands the check to PAM, which is consistent with Alpine listing that setup as unaffected.

Threat model. The attacker needs only network reach to TCP 22 (or wherever sshd listens). Per Alpine, they also need a target account with * in the password field and at least one other local account with a normal SHA-256 or SHA-512 crypt hash ($5$ or $6$). The target set is predictable: root (only with PermitRootLogin yes), key-only service and deploy users, directory-service users via musl-nscd, and the alpine user on tiny-cloud images.

In practice: tiny-cloud images. Alpine says its official cloud images from 3.18.11 through 3.24.3 ship an alpine user with a * password and passwordless doas. That makes a single login a direct route to root once any $6$ hash exists on the machine, for example after someone sets a password for a second user. Images built from the fixed point releases (3.21.10, 3.22.8, 3.23.8, 3.24.4) include the fix. Older running instances don't update themselves; each needs the package update or password logins turned off.

Controls. - Patch to the fixed package for the branch and restart sshd. Verify the running binary, not just the package: after the restart, the sshd process start time should be later than the package install time. - Set PasswordAuthentication no globally, then check every Match block in sshd_config and its included files, because a Match block can turn password logins back on for some users or addresses. sshd -T shows the global result; sshd -T -C user=<name>,host=<host>,addr=<ip> evaluates a specific connection against the Match rules. - Keep PermitRootLogin at prohibit-password or no. - Restrict TCP 22 to management networks or a bastion. In my judgement, a container that needs no inbound SSH shouldn't run sshd at all; docker exec or kubectl exec usually covers the same need under the orchestrator's access controls. - Alpine lists locked accounts (! in the password field) as unaffected. If you lock key-only accounts as a hardening step, test on one machine that key-based login still works for them before rolling it out.

Detection and evidence. On Alpine hosts using the default syslog, sshd writes to /var/log/messages. In containers, check where logs actually go: often stdout, collected by the runtime or your log platform, and lost when the container is replaced if nobody ships them. Alert on any Accepted password for event whose user appears in /etc/shadow with * or has no shadow entry. Previdian's account, as reported by Help Net Security, says the attacker ran reconnaissance commands such as id, uname and hostname after logging in. Those are generic, so treat them as context for an alert rather than a detection on their own. Then review doas logs, /etc/passwd and /etc/shadow modification times, every authorized_keys file, cron entries and outbound connections. Logs that rotate quickly or were never kept limit what a clean result proves.

Ask your team or provider: Which images in our registry install openssh-server, and which running containers were built from them before the fix? Which cloud instances came from tiny-cloud images 3.18.11 to 3.24.3? Is sshd reachable from the internet anywhere? How long do we keep SSH authentication logs, and do they survive a container restart?

Key takeaways

  • CVE-2026-123158 (SSHole) lets an unauthenticated attacker log in to accounts with no usable password on OpenSSH before 10.6p2, on Linux with musl and without PAM, mainly Alpine.
  • Fixed in OpenSSH 10.6p2 and in Alpine packages for 3.16 to edge, from 5 November 2026. Restart sshd after updating.
  • CISA added it to KEV on 9 November 2026 with a 12 November due date for US federal agencies. Previdian's sensors saw a first exploitation attempt on 6 November, the day after CVE publication.
  • Red Hat says its products are not affected. Alpine containers that don't run sshd are not affected. Debian and Ubuntu had not given a final status on 10 November.
  • If you can't patch, set PasswordAuthentication no, check Match blocks, and confirm key logins work first.
  • Search for Accepted password for on password-less accounts, and treat any hit as a compromise.

Sources

Spotted a mistake? Report a correction.