MAG212 CYBER ORIGINAL ARTICLE

OpenSSH “sshole” (CVE-2026-123158): Oversized Passwords Log In to Alpine and musl Linux, Now Exploited

November 10, 2026 · El Mostafa Ouchen

MAG212 CYBER illustration: a terminal-style login prompt receiving an over-long password string, headline 'OpenSSH sshole: an oversized password opens the door'.

Attackers are logging in to Alpine Linux and other musl-based systems over SSH without knowing any password. The flaw, nicknamed “sshole” and tracked as CVE-2026-123158, lets a password of 257 to 1,024 bytes unlock accounts whose password field is just an asterisk. OpenSSH shipped a fix on 5 November, the first exploitation attempt against a honeypot was reported within hours, and on 9 November CISA added the bug to its Known Exploited Vulnerabilities (KEV) catalog with a federal deadline of 12 November.

CVECVE-2026-123158 (CWE-394, unexpected return value)
Affectedsshd on Linux built with musl libc and without PAM (Alpine’s openssh-server, or openssh-server-pam with UsePAM no)
Fixed inOpenSSH 10.6p2 upstream; Alpine packages for every branch from 3.16 to edge (table below)
ExploitedYes. CISA KEV, honeypot root access reported, botnet and cryptominer activity reported
DeadlineAdded to KEV 9 Nov 2026, federal due date 12 Nov 2026, forensic triage flagged
WorkaroundPasswordAuthentication no, or disable SSH on the host
CVSSNot verified (no vendor or NVD score confirmed at press time)

What happened

OpenSSH 10.6p2, released on 5 November 2026, includes an sshd change to avoid a password-authentication bypass on some Linux systems built and run without PAM. The project describes it as a critical workaround for Linux systems that combine the musl C library with PAM disabled, and notes that the root cause sits outside sshd itself (OpenSSH release notes). Alpine Linux published its own advisory the same day (Alpine advisory).

Exploitation followed almost immediately. Previdian reported a first attempt less than nine hours after the CVE was published and confirmed that the attacker reached root on an Alpine honeypot (Help Net Security); that timing is a single-source claim. SecurityWeek reported on 9 November that botnets and cryptominers are now using the flaw (SecurityWeek). The same day, CISA added CVE-2026-123158 to KEV, describing it as an unexpected return value that could allow authentication bypass, with a three-day due date and a forensic-triage requirement (CISA KEV). OpenSSH’s Damien Miller urged affected users to switch off password authentication or disable SSH immediately rather than wait for a maintenance window (Help Net Security).

Who is affected

Alpine is precise about the conditions. A host is exploitable only when all of the following are true (Alpine advisory):

  1. sshd is the openssh-server package built without PAM, or openssh-server-pam running with UsePAM no;
  2. PasswordAuthentication yes is in effect, which is the default;
  3. a target account has * in its password field;
  4. another local account has a $5$ or $6$ password hash;
  5. the attacker sends a password between 257 and 1,024 bytes long.

Hosts are not affected if they run openssh-server-pam with UsePAM yes, have password authentication disabled, lock accounts with ! rather than *, have no $-style hashes, or are containers that never start sshd. Root logins are protected by the default PermitRootLogin prohibit-password, unless another login-capable account can escalate, for example through doas.

Alpine says its affected tiny-cloud images run from 3.18.11 to 3.24.3, and the fixed point releases are 3.21.10, 3.22.8, 3.23.8 and 3.24.4. According to SOCRadar, as reported by Help Net Security, those AWS and Azure tiny-cloud images also ship a default alpine user with passwordless doas, which turns a non-root login into root (Help Net Security).

Alpine branchFixed openssh package
edge10.6_p2-r0
3.2410.3_p1-r2
3.2310.2_p1-r1
3.2210.0_p1-r11
3.219.9_p2-r1
3.209.7_p1-r6
3.199.6_p1-r3
3.189.3_p2-r4
3.179.1_p1-r7
3.169.0_p1-r6

Source: Alpine advisory.

The researcher behind the finding, Özgün Kültekin of Wakefield, also names OpenWrt, Buildroot, Yocto and many Docker images as musl-based systems worth checking. Debian, Ubuntu, Fedora, Dropbear and OpenBSD are reported as not affected (Help Net Security). MAG212 CYBER analysis: the biggest real-world exposure is Alpine-based containers and VMs that run sshd, plus embedded builds. Many OpenWrt-based routers and access points use Dropbear rather than OpenSSH, so check each vendor rather than assume either way; we found no network-vendor advisory at press time.

How the attack works

Without PAM, sshd checks each password attempt by hashing it with crypt(). When an account’s stored field is too short to contain a salt, sshd borrows another account’s salt so the comparison still runs. Alpine explains that musl’s crypt() fails on keys longer than 256 bytes and returns the string *. If the target account’s stored password field is also *, the two match and sshd accepts the login (Alpine advisory).

Diagram of the OpenSSH sshole bypass: an oversized password makes musl crypt fail and return an asterisk, which matches an asterisk password field so the login is accepted; the five required conditions are listed below.
How the sshole bypass works, and the five conditions that must all be true (based on the Alpine advisory). Diagram: MAG212 CYBER

In Previdian’s honeypot the attacker ran id, uname and hostname after logging in, the usual first look around (Help Net Security). We do not yet know how many hosts are exposed worldwide or what payloads attackers deploy beyond the botnet and cryptominer activity SecurityWeek reported.

What to look for

  • Successful password logins on passwordless accounts. Alpine advises searching /var/log/messages for Accepted password for on accounts such as alpine, root and key-only users (Alpine advisory).
  • Post-login activity. Review doas use, newly created users and changes to authorized_keys files.
  • One published source address. All eight attempts Previdian observed came from 89.116.89[.]18 (Help Net Security). Treat it as a single data point, not a blocklist.

Investigate, contain and fix

  1. Stop the bleeding. If you cannot patch right now, disable password authentication (drop-in file below) or turn SSH off on the host.
  2. Patch. Upgrade to the fixed package for your Alpine branch, or to OpenSSH 10.6p2 upstream.
  3. Restart sshd. Alpine notes that upgrading the package does not restart a running sshd.
  4. Hunt. Run the log and account checks above on every host that met all five conditions.
  5. Decide on compromise. Alpine’s advice is blunt: “If a login cannot be ruled out, treat the machine as compromised” (Alpine advisory). For containers and cloud images that usually means rebuilding from a patched image and rotating any credentials the host held (MAG212 CYBER analysis).

Alpine Linux, root shell, makes changes: upgrade all packages including openssh, then restart sshd.

apk upgrade -U -a
rc-service sshd restart

Alpine Linux, root shell, makes changes (workaround): create /etc/ssh/sshd_config.d/00-no-passwords.conf containing the single line PasswordAuthentication no, then validate the configuration and restart only if validation passes.

sshd -t && rc-service sshd restart

Alpine Linux, root shell, read-only: confirm the effective setting.

sshd -T | grep -i passwordauthentication

MAG212 CYBER did not test these commands; syntax is taken from the cited source. Read the vendor advisory before running anything in production. Source for all three: Alpine advisory.

How to confirm you’re clean

  • The installed openssh package matches or exceeds the fixed version for your branch.
  • sshd was restarted after the upgrade (check the process start time).
  • sshd -T reports passwordauthentication no wherever you applied the workaround.
  • A fresh log search shows no new Accepted password for entries for passwordless accounts.

Lessons for admins, staff and leaders

  • Admins: make key-only SSH the baseline everywhere, and don’t run sshd inside containers that don’t need it. Base images inherit their operating system’s authentication quirks.
  • Security teams: Previdian warns that proof-of-concept code circulating on GitHub is unverified and may itself contain malware (Help Net Security). Don’t run it to “test” production.
  • Leaders: a three-day KEV deadline with forensic triage is CISA’s signal that this is being used now. Ask for an inventory of Alpine and other musl-based hosts that expose SSH, with an owner for each.

What we still don’t know

  • A verified CVSS score from the vendor or NVD.
  • How many internet-facing hosts meet all five conditions.
  • What attackers install after logging in, beyond the reported botnets and cryptominers.
  • Whether network and IoT vendors that build on OpenWrt, Buildroot or Yocto ship vulnerable OpenSSH builds.

Related on MAG212 CYBER

Sources