Ing. Calogero Bono
Le 5 novembre 2026 est sorti OpenSSH 10.6p2, qui corrige un bug baptisé «*sshole». Il concerne les serveurs SSH sous Linux qui utilisent la bibliothèque musl, comme Alpine Linux, avec PAM désactivé. Quiconque atteint le port SSH peut entrer dans un compte sans mot de passe en envoyant un mot de passe très long. C'est important parce qu'une seule connexion suffit et parce que les images cloud officielles d'Alpine peuvent donner un accès root.
Quelques termes, avant d'entrer dans les faits. musl est une bibliothèque C alternative à glibc, utilisée par Alpine, OpenWrt, Buildroot et Yocto. crypt() est la fonction qui transforme un mot de passe en son hash. PAM est le système modulaire d'authentification de Linux. /etc/shadow est le fichier qui conserve les hashs des mots de passe. doas est l'outil, semblable à sudo, qui permet d'obtenir les privilèges root.
Comment fonctionne le bug *sshole ?
Un compte Linux sans mot de passe a un astérisque à la place du hash dans /etc/shadow. Aucun mot de passe ne devrait l'ouvrir. Selon BleepingComputer, une modification d'OpenSSH de 2016, née pour corriger la CVE-2016-6210 sur l'énumération des utilisateurs, fait calculer le hash aussi pour ces comptes.
C'est là qu'intervient musl. Comme l'explique l'avis d'Alpine, la fonction crypt() de musl renvoie * comme signal d'erreur si la clé dépasse 256 octets. Cet astérisque correspond à celui enregistré dans le compte, et la comparaison réussit. Le chercheur Özgün Kültekin affirme que le défaut existe depuis 2016.
Qui est vraiment exposé ?
Plusieurs conditions doivent être réunies. Selon Alpine, le paquet openssh-server est compilé sans PAM, ou bien on utilise openssh-server-pam avec UsePAM no. PasswordAuthentication doit être actif, comme par défaut. Il faut un compte avec * et au moins un autre avec un hash $5$ ou $6$. Un seul utilisateur avec mot de passe suffit à rendre accessibles tous les autres.
Alpine a vérifié les versions de la 3.21 à la 3.24 et edge, ainsi que les anciennes 3.16 à 3.20. Ne sont pas touchés les conteneurs sans sshd, les systèmes avec PasswordAuthentication no et les systèmes avec PAM actif. Debian, Ubuntu et Fedora, qui utilisent glibc, ne sont pas vulnérables, écrit BleepingComputer.
Pourquoi les images cloud d'Alpine inquiètent-elles ?
Les images officielles tiny-cloud, de la 3.18.11 à la 3.24.3, ont un utilisateur alpine avec le mot de passe * et doas sans mot de passe. Alpine précise qu'elles sont sûres au premier démarrage. Elles deviennent exploitables lorsqu'apparaît un hash $6$, par exemple si un administrateur définit un mot de passe de console ou si user-data ajoute un utilisateur avec hashed_passwd.
Dans ce cas, l'attaquant obtient un shell en tant que alpine et, avec doas, devient root. Les images configurées avec cloud-init, qui écrit PasswordAuthentication no, ne sont pas touchées. Pour root, la valeur par défaut PermitRootLogin prohibit-password ne protège que de manière directe.
Comment corriger et détecter une attaque ?
La correction se trouve dans OpenSSH 10.6p2. Sur Alpine, on utilise apk upgrade -U -a, puis on redémarre sshd, car la mise à jour ne remplace pas le démon déjà en cours. Alpine a publié des paquets corrigés jusqu'à la 3.16, y compris pour les versions qui ne sont plus supportées.
Si tu ne peux pas mettre à jour, mets PasswordAuthentication no et redémarre sshd, après avoir vérifié que l'accès par clé fonctionne. Pour chercher des traces, examine dans /var/log/messages les lignes «Accepted password» concernant des comptes sans mot de passe. Alpine ajoute que, si tu ne peux pas exclure un accès, la machine doit être considérée comme compromise. Pour les permissions des comptes, consulte aussi le guide sur les permissions Linux.
Limites à connaître
Alpine indique qu'au moment de la publication aucun CVE n'avait été attribué. OpenSSH écrit que la cause se situe hors de sshd, mais qu'elle est exploitable via sshd, où elle est évitée. Aucune donnée n'indique d'attaques réelles en cours. Les affirmations sur les 17 600 tests menés avec des agents IA viennent du chercheur, rapportées par BleepingComputer, et ne sont pas vérifiées de manière indépendante.
Ce qui change pour ceux qui travaillent dans le numérique
Si tu gères des serveurs Alpine, des routeurs OpenWrt ou des systèmes embarqués avec Yocto et Buildroot, vérifie si sshd accepte les mots de passe et s'il existe des comptes avec *. Beaucoup utilisent Alpine dans des conteneurs sans sshd et ne sont pas concernés. Ceux qui exploitent des machines cloud avec les images tiny-cloud doivent contrôler chaque instance déjà en service. Un serveur géré avec des mises à jour régulières réduit ce type de risque, nous en parlons sur la page consacrée à l'hébergement et aux serveurs gérés. Il est aussi utile de suivre le cas lié aux exploits générés par l'IA, dont nous avons parlé dans cet article.
Notre avis
Ce cas montre à quel point la frontière entre composants qui se font confiance est fragile. OpenSSH a ajouté une défense légitime en 2016, musl a choisi une valeur d'erreur courante, et ensemble ils ont ouvert une porte pendant dix ans. Il est aussi frappant que le bug ait été trouvé avec des agents IA. OpenSSH elle-même prévient que les bugs trouvés grâce à l'IA sont souvent redécouverts par d'autres, donc attendre est un risque. Le remède le plus solide reste le même depuis toujours – des clés à la place des mots de passe.
Questions fréquentes
Debian et Ubuntu sont-ils vulnérables à *sshole ?
Non. Ils utilisent glibc et non la bibliothèque musl. BleepingComputer confirme que les systèmes avec authentification PAM ne sont pas vulnérables, mais Alpine précise que openssh-server-pam avec UsePAM no l'est aussi, alors qu'avec UsePAM yes il ne l'est pas.
Suffit-il de mettre à jour le paquet openssh ?
Non, il faut aussi redémarrer sshd. Alpine précise que la mise à jour ne remplace pas le démon déjà en cours d'exécution, donc la version vulnérable resterait active.
Puis-je me protéger sans mettre à jour ?
Oui, de façon temporaire. Mets PasswordAuthentication no dans la configuration de sshd et redémarre le service. Vérifie d'abord que l'accès par clé fonctionne.
Le compte root est-il aussi exposé ?
Seulement dans certains cas. Avec PermitRootLogin prohibit-password, la valeur par défaut, root n'est pas accessible directement. Il le devient si PermitRootLogin yes est actif ou si un autre utilisateur peut devenir root, par exemple avec doas.
Existe-t-il un CVE pour ce bug ?
Pas encore, selon Alpine. L'avis indique qu'au moment de la rédaction aucun identifiant n'avait été attribué. La référence reste les notes de version d'OpenSSH 10.6p2.
Que surveiller après OpenSSH 10.6p2
OpenSSH a annoncé des versions plus fréquentes pour apporter plus vite les corrections aux utilisateurs. Ce bug laisse quelques questions ouvertes à suivre.
- Vérifie si un CVE sera attribué et si tes outils de scan le reconnaîtront.
- Surveille quand les fabricants de firmware basés sur OpenWrt, Buildroot et Yocto publieront leurs mises à jour.
- Prépare une routine pour installer les versions mineures d'OpenSSH sans attendre les versions planifiées.
