Faille *sshole : un mot de passe de 257 caractères ouvrait OpenSSH sur Alpine et les systèmes musl

Le 5 novembre 2026, le projet OpenSSH a publié la version 10.6p2, présentée dans ses notes de version comme un correctif de sécurité « critique » pour les systèmes Linux qui utilisent la bibliothèque musl avec PAM désactivé. Musl est une bibliothèque C standard, alternative à la glibc, choisie pour sa légèreté par Alpine Linux et par de nombreux systèmes embarqués ; PAM (Pluggable Authentication Modules) est le mécanisme qui délègue la vérification des identifiants à des modules configurables. Le même jour, Alpine, base d’une grande partie des images de conteneurs, a publié des paquets corrigés pour toutes ses branches depuis la 3.16, y compris celles qui ne sont plus maintenues. Sur ces systèmes, un compte marqué d’un astérisque dans /etc/shadow, le fichier où sont stockées les empreintes des mots de passe locaux, acceptait n’importe quel mot de passe de 257 à 1 024 octets, en une seule connexion, dès qu’un autre compte de la machine possédait un vrai mot de passe.

La faille a été découverte par Özgün Kültekin, de la société Wakefield, qui l’a baptisée *sshole en référence à cet astérisque. Aucune exploitation n’a été signalée à ce jour. L’avis d’Alpine précise qu’aucun identifiant CVE n’avait été attribué au moment de sa rédaction ; plusieurs éditeurs de sécurité citent pourtant un identifiant et un score CVSS de 8,1 qu’on ne retrouve dans aucun avis officiel. Cet article détaille le mécanisme, qui associe des choix faits par trois projets entre 2012 et 2022, délimite les configurations réellement exposées, puis décrit les vérifications à mener sur un parc de serveurs et d’images.

Un astérisque qui sert à la fois de verrou et de code d’erreur

Chaque ligne de /etc/shadow associe un compte à l’empreinte de son mot de passe, calculée par une fonction de hachage à partir du mot de passe et d’un sel, une valeur aléatoire propre au compte. À la place d’une empreinte, le champ peut contenir un astérisque, qui signifie qu’aucun mot de passe ne doit ouvrir le compte. C’est la valeur réservée aux comptes de service, aux utilisateurs qui ne se connectent qu’avec une clé SSH et, sur Alpine depuis la version 3.16, au compte root. Le point d’exclamation sert, lui, à verrouiller un compte, mais selon le chercheur, sshd compilé sans PAM refuse alors toute connexion, y compris par clé : les administrateurs qui veulent un compte accessible par clé seulement lui donnent donc un astérisque.

Pour vérifier un mot de passe, sshd appelle la fonction crypt() de la bibliothèque C, qui recalcule l’empreinte du mot de passe saisi avec le sel et l’algorithme du compte, puis compare le résultat à la valeur stockée. Lorsque le compte n’a pas d’empreinte exploitable, sshd effectue quand même un calcul avec le sel d’un autre compte de la machine. Ce comportement date d’OpenSSH 7.3, en août 2016, qui corrigeait la CVE-2016-6210 : en mesurant le temps de réponse du serveur à de très longs mots de passe, un attaquant pouvait deviner quels noms de comptes existaient.

Depuis août 2012, la fonction crypt() de musl signale un échec en renvoyant la chaîne *, et ses implémentations de SHA-256 et SHA-512, les algorithmes des empreintes qui commencent par $5$ et $6$, refusent les mots de passe de plus de 256 octets. D’autres bibliothèques signalent l’échec par un pointeur nul ou, comme libxcrypt, par une chaîne *0 ou *1 choisie pour ne correspondre à aucune valeur stockée. Sur musl, un mot de passe de 257 octets fait échouer le calcul, crypt() renvoie *, et sshd compare cet astérisque à celui qui figure dans /etc/shadow : les deux chaînes sont identiques, la session s’ouvre. La borne de 1 024 octets correspond à la longueur maximale qu’OpenSSH accepte pour un mot de passe, elle aussi depuis la version 7.3 (CVE-2016-6515). Si aucun autre compte ne possède d’empreinte SHA-256 ou SHA-512, sshd n’a pas de sel de ce type à emprunter et le contournement échoue, ce qui protège une machine fraîchement installée sur laquelle aucun mot de passe n’a été défini.

Des choix faits séparément entre 2012 et 2022

Date	Changement	Projet
Août 2012	crypt() renvoie * en cas d’échec, puis refuse les mots de passe de plus de 256 octets en SHA-256 et SHA-512	musl
Août 2016	sshd emprunte le sel d’un autre compte pour les comptes sans empreinte (CVE-2016-6210) et refuse les mots de passe de plus de 1 024 caractères (CVE-2016-6515)	OpenSSH 7.3
2019	Le compte root des images Docker officielles, livré avec un mot de passe vide, est verrouillé par ! (CVE-2019-5021)	Alpine
2022	Le compte root passe de ! à * avec la version 3.16	Alpine
5 novembre 2026	OpenSSH 10.6p2, paquets corrigés pour les branches 3.16 à edge, versions 3.21.10, 3.22.8, 3.23.8 et 3.24.4	OpenSSH, Alpine

Selon le chercheur, le problème a été frôlé deux fois sans être relié à sshd : dans un rapport de bogue Debian de 2013, puis en décembre 2024 dans une discussion de la liste de diffusion de musl sur la commande passwd de BusyBox. Il dit l’avoir trouvé en novembre 2026 en compilant sshd dans toutes les combinaisons qu’il pouvait imaginer (glibc ou musl, avec ou sans PAM, avec ou sans fichier shadow) et en soumettant environ 17 600 tentatives de connexion inhabituelles, à l’aide de nombreux agents d’IA. Toutes les compilations ont donné les mêmes réponses, sauf celle qui associe musl à l’absence de PAM.

Le rapprochement avec XZ Utils vient vite à l’esprit. En mars 2024, on découvrait qu’un contributeur, après deux ans de participation au projet, avait inséré du code malveillant dans cette bibliothèque de compression pour introduire une porte dérobée dans sshd sur certaines distributions (CVE-2024-3094). Les notes d’OpenSSH, l’avis d’Alpine, les messages du mainteneur de musl et le récit du chercheur décrivent la rencontre de trois comportements documentés, publiés entre 2012 et 2022 par des projets distincts.

Un correctif côté OpenSSH, un changement annoncé côté musl

L’équipe d’OpenSSH écrit qu’elle situe « la cause première de ce bogue hors de sshd », tout en reconnaissant qu’il s’exploite par sshd et qu’il peut y être évité. Le correctif, signalé sur la liste oss-security par Jan Schaumann, fait vérifier à sshd que la valeur stockée atteint la longueur minimale d’une empreinte avant toute comparaison, ce qui retire tout effet à un astérisque isolé. Damien Miller et Darren Tucker ont préparé la version, Natanael Copa les paquets d’Alpine.

Rich Felker, mainteneur de musl, a répondu le même jour sur la liste du projet que le comportement de crypt() relève selon lui d’une « utilisation erronée par l’appelant », et annoncé que ce mécanisme sera « très probablement » modifié lors du prochain cycle de versions. Il précise que la faille se limite à OpenSSH : Dropbear, le serveur SSH léger utilisé notamment par OpenWrt, y échappe, y compris dans ses anciennes versions. Tant que musl n’a pas changé, un programme maison qui compare le résultat de crypt() à une valeur stockée sans en contrôler la forme reproduirait la même erreur que sshd.

Quels serveurs et quels conteneurs sont exposés ?

Les cinq conditions suivantes doivent être réunies, d’après l’avis d’Alpine :

• un sshd d’OpenSSH antérieur à 10.6p2, compilé avec musl ;
• PAM désactivé, ce qui est le cas par défaut du paquet openssh-server d’Alpine, ou du paquet openssh-server-pam configuré avec UsePAM no ;
• l’authentification par mot de passe active (PasswordAuthentication yes), valeur par défaut d’OpenSSH ;
• un compte dont le champ de mot de passe vaut exactement * ;
• au moins un autre compte doté d’une empreinte SHA-256 ou SHA-512.

Le compte root d’Alpine porte un astérisque, mais l’option par défaut PermitRootLogin prohibit-password interdit à root toute connexion par mot de passe. Alpine souligne que le risque passe par un autre compte vulnérable qui peut ensuite obtenir les droits de root par doas, l’équivalent de sudo sur cette distribution. Les comptes les plus exposés sont donc les comptes de déploiement ou de service réservés aux clés SSH et, selon le chercheur, les utilisateurs d’un annuaire LDAP dont l’entrée locale porte un astérisque.

Les images cloud officielles d’Alpine construites avec tiny-cloud, l’outil léger d’initialisation des instances cloud propre à Alpine, de la version 3.18.11 à la 3.24.3, créent un utilisateur alpine sans mot de passe (*) qui peut utiliser doas sans saisir de mot de passe. Elles sont sûres au premier démarrage, et deviennent exploitables, jusqu’aux droits de root, dès qu’une empreinte $6$ apparaît sur la machine, par exemple un mot de passe de console ou un champ hashed_passwd dans les données utilisateur. Les images configurées par cloud-init, l’outil d’initialisation le plus répandu, qui écrit PasswordAuthentication no, échappent à la faille.

L’image Docker de base alpine ne contient pas de serveur SSH, et Alpine précise que les conteneurs qui ne font pas tourner sshd ne sont pas concernés. Le risque se concentre sur les images construites pour offrir un accès SSH : bastions, conteneurs de développement, agents d’intégration continue, images qui ajoutent openssh-server pour transférer des fichiers. Le chercheur cite « beaucoup des images Docker » parmi les systèmes musl, sans recensement publié. OpenWrt n’est exposé que si OpenSSH y remplace Dropbear, et Buildroot ou Yocto, outils de construction de systèmes Linux embarqués, seulement lorsque la configuration du firmware associe OpenSSH, musl et l’absence de PAM. Les distributions fondées sur la glibc et PAM (Debian, Ubuntu, Red Hat et leurs dérivées) restent hors de cause : selon le chercheur, PAM n’appelle jamais crypt() pour un compte marqué d’un astérisque.

Corriger les serveurs, puis rechercher une connexion anormale

L’inventaire vient en premier : il s’agit de recenser les machines, les appliances et les images où tourne un sshd lié à musl. La présence d’un fichier /lib/ld-musl-*.so.1 signale une base musl, et apk list -I | grep openssh donne la version installée sur Alpine. Les versions corrigées du paquet openssh sont les suivantes :

Branche Alpine	Version corrigée
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

La mise à jour (apk upgrade -U -a) remplace le paquet sans relancer le démon en cours d’exécution : le correctif ne s’applique qu’après rc-service sshd restart. Pour les conteneurs, la correction passe par la reconstruction des images à partir d’une base à jour, puis par leur redéploiement ; un conteneur corrigé à la main disparaît au prochain déploiement.

Lorsqu’une machine ne peut pas être mise à jour tout de suite, la désactivation de l’authentification par mot de passe ferme la faille. sshd retient la première valeur qu’il lit pour chaque option : la ligne PasswordAuthentication no doit donc figurer en tête de /etc/ssh/sshd_config, ou dans un fichier de /etc/ssh/sshd_config.d/ si la configuration l’inclut, avant toute ligne qui l’active. La commande sshd -t valide la configuration avant le redémarrage, et sshd -T, lancée en root, affiche la valeur effectivement appliquée. Sur un serveur accessible depuis Internet, cette configuration par clé seule vaut d’être conservée après le correctif, car elle écarte aussi les attaques par force brute sur les mots de passe.

Reste à vérifier qu’aucun accès n’a eu lieu. Les comptes marqués d’un astérisque se listent avec awk -F: '$2 == "*" {print $1}' /etc/shadow, et les connexions par mot de passe apparaissent dans les journaux sous la forme Accepted password for, dans /var/log/messages avec la configuration par défaut d’Alpine ; centraliser ces journaux dans un SIEM, comme le décrit notre article sur la gestion des événements de sécurité, permet de mener la recherche sur tout un parc à la fois. Une telle ligne pour l’un de ces comptes signale, d’après les analyses d’Orca Security et d’OX Security, une compromission probable : la machine se traite alors comme un incident, avec son isolement, sa reconstruction et le renouvellement des clés et des secrets qu’elle contenait. Si elle traitait des données personnelles, l’accès non autorisé constitue une violation à notifier à la CNIL dans les 72 heures, au titre de l’article 33 du RGPD, à moins qu’elle ne soit pas susceptible d’engendrer un risque pour les droits et libertés des personnes concernées.

Sources et références 13 sources

Avis officiels

1. [1] OpenSSH : notes de version 10.6p2 (5 novembre 2026) et 7.3 (août 2016)
2. [2] Alpine Linux : avis sur le contournement de l'authentification par mot de passe d'OpenSSH (5 novembre 2026)
3. [3] Jan Schaumann, liste oss-security : « sshole », password authentication bypass, OpenSSH + musl libc (5 novembre 2026)
4. [4] Rich Felker, liste musl : position du mainteneur et changement annoncé (5 novembre 2026)
5. [5] Rich Felker, liste musl : Dropbear non concerné, y compris dans ses anciennes versions (6 novembre 2026)

Découverte

1. [6] Özgün Kültekin (Wakefield) : *sshole, récit de la découverte et chronologie

Analyses

1. [7] Orca Security : *sshole, OpenSSH authentication bypass on Alpine Linux (novembre 2026)
2. [8] OX Security : OpenSSH password authentication bypass on Alpine Linux (novembre 2026)
3. [9] BleepingComputer : OpenSSH flaw lets attackers log into password-disabled Linux accounts (novembre 2026)

Vulnérabilités antérieures citées

1. [10] NVD : CVE-2016-6210, énumération des comptes par mesure du temps de réponse de sshd
2. [11] NVD : CVE-2016-6515, déni de service par mots de passe très longs dans sshd
3. [12] NVD : CVE-2019-5021, mot de passe root vide dans les images Docker officielles d'Alpine
4. [13] CISA : Reported Supply Chain Compromise Affecting XZ Utils Data Compression Library, CVE-2024-3094 (mars 2024)