sshole — contournement d'authentification OpenSSH sur Alpine

Note défensive. Cet article décrit une vulnérabilité publique à des fins de compréhension et de remédiation. N'appliquez ces vérifications que sur vos propres systèmes ou ceux pour lesquels vous disposez d'une autorisation écrite.

En bref

CVE-2026-123158 — contournement de l'authentification par mot de passe dans sshd. Score CVSS 3.1 : 8,1 / 10 (élevé).
Découverte par Özgün Kültekin, divulguée le 5 novembre 2026.
Concernés : OpenSSH compilé avec la libc musl et sans PAM — soit le paquet openssh-server par défaut d'Alpine, ainsi qu'OpenWrt, Buildroot, Yocto.
Épargnés : les systèmes glibc (Debian, Ubuntu, Fedora…) et tout système qui authentifie via PAM.
Correctif publié en moins de 24 h : OpenSSH 10.6p2 et paquets Alpine à jour, le 5 novembre 2026.

La cause : deux bonnes idées qui s'annulent

Le bug naît de la combinaison de deux comportements parfaitement raisonnables pris séparément.

Côté musl. Depuis 2012, la fonction crypt() de la libc musl ne renvoie plus NULL en cas d'échec, mais la chaîne * (un simple astérisque).

Côté OpenSSH. Depuis 2016, pour corriger la CVE-2016-6210 (énumération d'utilisateurs par mesure du temps de réponse), sshd calcule toujours une empreinte, même pour un compte qui n'a pas de hash exploitable — en réutilisant pour cela le sel d'un autre compte.

Maintenant, assemblons : si un attaquant envoie un mot de passe très long (de l'ordre de 257 à 1 024 caractères selon le chercheur), crypt() échoue et renvoie *. Or dans /etc/shadow, un compte sans mot de passe utilisable (root, compte par clé, compte d'annuaire) porte justement l'empreinte *. Les deux valeurs coïncident : sshd conclut que le mot de passe est bon et accepte la connexion.

En clair : le code censé masquer l'existence d'un compte finit par valider une authentification pour ce même compte.

Conditions d'exploitation (toutes requises)

sshd tourne sans PAM (défaut sur Alpine, ou openssh-server-pam avec UsePAM no).
L'authentification par mot de passe est activée (réglage par défaut).
Un compte cible possède l'empreinte * dans shadow (compte par clé, compte sans mot de passe…). Les comptes verrouillés par ! ne sont pas concernés.
Au moins un autre compte local possède un vrai hash SHA-256/512 : c'est lui qui fournit le sel.

Sur les images cloud officielles d'Alpine (AWS, Azure), de la 3.18.11 à la 3.24.3, le compte alpine n'a pas de mot de passe mais peut passer root via doas sans en saisir : c'est le scénario le plus à risque. Par défaut, le compte root reste protégé par PermitRootLogin prohibit-password — sauf s'il a été basculé sur yes.

Quel impact, vraiment ?

Il s'agit d'un contournement d'authentification, pas d'une exécution de code à distance. Mais l'effet reste sérieux : sur une image cloud Alpine, obtenir une session sur le compte alpine revient le plus souvent à obtenir root via doas. Les conteneurs Docker Alpine qui n'exposent pas SSH ne sont pas affectés.

Suis-je exposé ?

En root, une seule commande suffit à trancher :

sshd -T | grep -i -E 'passwordauthentication|usepam'

Vous n'êtes pas exposé si l'authentification par mot de passe est désactivée (passwordauthentication no) ou si PAM est actif (usepam yes).

Pour chasser une éventuelle compromission, cherchez les connexions par mot de passe acceptées sur des comptes qui n'en ont pas :

grep "Accepted password" /var/log/messages

Correctifs

Mettre à jour, c'est le plus simple :

apk upgrade -U -a
rc-service sshd restart

Alpine a rétroporté le correctif sur toutes les branches, de la 3.16 à edge :

edge  : openssh 10.6_p2-r0
3.24  : openssh 10.3_p1-r2
3.23  : openssh 10.2_p1-r1
3.22  : openssh 10.0_p1-r11
3.21  : openssh 9.9_p2-r1
3.20  : openssh 9.7_p1-r6
3.19  : openssh 9.6_p1-r3
3.18  : openssh 9.3_p2-r4
3.17  : openssh 9.1_p1-r7
3.16  : openssh 9.0_p1-r6

Si le patch est impossible (Alpine < 3.16, ou contrainte de prod), désactivez l'authentification par mot de passe après avoir validé votre connexion par clé :

# /etc/ssh/sshd_config
PasswordAuthentication no

N'oubliez pas de reconstruire et redéployer les images de conteneurs qui embarquent un vieux paquet openssh.

À retenir

Une faille critique ne vient pas toujours d'un seul composant : ici, c'est l'interaction entre musl et OpenSSH qui crée le trou, chacun étant « correct » de son côté.
musl + sans PAM est un terrain à surveiller : c'est la configuration par défaut d'Alpine, très présente dans les images conteneurs.
La mitigation la plus robuste reste intemporelle : authentification par clé, mot de passe désactivé.

Sources : avis Alpine Linux et analyse Cycode (CVE-2026-123158), 5 novembre 2026.