ARTICLE ORIGINAL MAG212 CYBER

La faille “ sshole ” d'OpenSSH (CVE-2026-123158) : des mots de passe trop longs permettent de se connecter à Alpine et musl Linux, une vulnérabilité désormais exploitée.

10 novembre 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)
Affectésshd on Linux built with musl libc and sans PAM (Alpine’s openssh-server, or openssh-server-pam avec UsePAM no)
Fixé dansOpenSSH 10.6p2 upstream; Alpine packages for every branch from 3.16 to edge (table below)
ExploitéYes. 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)

Ce qui s'est passé

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 (Conseil alpin).

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 (Aide à la sécurité du réseau); that timing is a single-source claim. SecurityWeek reported on 9 November that botnets and cryptominers are now using the flaw (Semaine de la sécurité). 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 (Aide à la sécurité du réseau).

Qui est concerné ?

Alpine is precise about the conditions. A host is exploitable only when tous of the following are true (Conseil alpin):

  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$ ou $6$ password hash;
  5. the attacker sends a password between 257 and 1,024 bytes long.

Hosts are pas affected if they run openssh-server-pam avec 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 (Aide à la sécurité du réseau).

branche alpineFixé openssh emballer
bord10.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: Conseil alpin.

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 (Aide à la sécurité du réseau). Analyse CYBER MAG212 : 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.

Comment fonctionne l'attaque

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 (Conseil alpin).

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 et hostname after logging in, the usual first look around (Aide à la sécurité du réseau). We do not yet know how many hosts are exposed worldwide or what payloads attackers deploy beyond the botnet and cryptominer activity SecurityWeek reported.

Que rechercher

  • Successful password logins on passwordless accounts. Alpine advises searching /var/log/messages pour Accepted password for on accounts such as alpine, root and key-only users (Conseil alpin).
  • Post-login activity. Revoir 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 (Aide à la sécurité du réseau). Treat it as a single data point, not a blocklist.

Enquêter, contenir et réparer

  1. Arrêtez le saignement. 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. Redémarrez 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. Optez pour un compromis. Alpine’s advice is blunt: “If a login cannot be ruled out, treat the machine as compromised” (Conseil alpin). 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): créer /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: Conseil alpin.

Comment confirmer que vous êtes propre

  • 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.

Leçons pour les administrateurs, le personnel et les dirigeants

  • Administrateurs : 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.
  • Équipes de sécurité : Previdian warns that proof-of-concept code circulating on GitHub is unverified and may itself contain malware (Aide à la sécurité du réseau). Don’t run it to “test” production.
  • Dirigeants : 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.

Ce que nous ignorons encore

  • 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.

Sujets connexes sur MAG212 CYBER

Sources