SSHole (CVE-2026-123158) : OpenSSH, Alpine et musl à corriger

SSHole, suivie sous l'identifiant CVE-2026-123158, permet de se connecter en SSH à certains comptes censés refuser tout mot de passe, sur les systèmes Linux qui utilisent la bibliothèque C musl (Alpine, OpenWrt, Buildroot, Yocto) avec OpenSSH sans PAM et l'authentification par mot de passe activée. Le correctif est dans OpenSSH 10.6p2. Si vous ne pouvez pas mettre à jour tout de suite, désactivez l'authentification SSH par mot de passe et redémarrez le service.

Ce qui s'est passé

Le 5 novembre 2026, le chercheur Özgün Kültekin a publié les détails d'une faille dans l'interaction entre OpenSSH et musl, une implémentation légère de la bibliothèque C standard (libc) utilisée notamment par Alpine Linux. BleepingComputer l'a décrite le jour même, puis SecurityWeek le 6 novembre.

Les éléments publiés :

• la faille porte l'identifiant CVE-2026-123158 et un score CVSS (l'échelle de gravité standard des vulnérabilités, de 0 à 10) de 8,1, selon SecurityWeek ;
• elle existe depuis 2016, d'après le chercheur ;
• elle est corrigée dans OpenSSH 10.6p2 ;
• Damien Miller, développeur d'OpenSSH, précise que le défaut n'est pas dans le serveur sshd lui-même, mais qu'il est exploitable à travers lui ;
• l'équipe OpenSSH a publié le correctif au plus vite, en expliquant avoir appris le problème la veille et considérer désormais les longues périodes d'embargo comme dangereuses, parce qu'elle a observé plusieurs cas de redécouverte rapide de bugs par des agents d'IA, parfois en quelques heures ;
• le chercheur indique avoir lui-même trouvé la faille avec des agents d'IA qui ont exécuté environ 17600 tests d'authentification sur des configurations OpenSSH variées.

Alpine Linux a demandé le jeudi 5 novembre d'appliquer le correctif immédiatement et de redémarrer sshd, ou, à défaut, de désactiver les connexions par mot de passe. Selon Alpine, les versions touchées sont toutes celles vérifiées, de 3.21 à 3.24 et edge, ainsi que les anciennes versions qui ne reçoivent plus de mises à jour régulières (3.16 à 3.20). Au moment de ces publications, Alpine n'avait pas connaissance d'exploitation, mais plusieurs chercheurs cités par SecurityWeek s'attendaient à voir des tentatives rapidement.

Comment ça fonctionne, en principe

Sous Linux, on bloque la connexion par mot de passe d'un compte en remplaçant son empreinte de mot de passe par un astérisque (*) dans /etc/shadow. Un astérisque n'est pas une empreinte valide : aucun mot de passe ne devrait donc correspondre. C'est la configuration normale des comptes qui ne se connectent que par clé, et Alpine l'applique au compte root depuis la version 3.16.

En 2016, OpenSSH a corrigé une faille d'énumération des noms d'utilisateurs (CVE-2016-6210) : un attaquant pouvait distinguer les comptes existants en mesurant le temps de réponse. Pour supprimer cet écart, OpenSSH calcule désormais une empreinte même quand le compte n'a pas d'empreinte utilisable, y compris pour les comptes marqués *.

Le problème vient de musl. Sa fonction crypt(), qui calcule l'empreinte, renvoie elle aussi * quand le calcul échoue, par exemple quand le mot de passe soumis dépasse sa limite de 256 octets. Le résultat de l'échec et la valeur stockée sont alors identiques, et la comparaison réussit. SecurityWeek parle d'une mauvaise interprétation de ce qui est, ou non, une empreinte de mot de passe, et de mots de passe de 257 à 1024 caractères.

Deux précisions importantes :

• la faille ne contourne pas les mots de passe des comptes qui ont une empreinte valide ;
• les systèmes basés sur glibc (Debian, Ubuntu, Fedora) et ceux qui utilisent PAM (Pluggable Authentication Modules, le cadre d'authentification modulaire de Linux) ne sont pas vulnérables, selon BleepingComputer.

Qui est concerné

Les cinq conditions publiées par le chercheur doivent être réunies :

1. OpenSSH tourne sur un système Linux basé sur musl : Alpine Linux, OpenWrt, Buildroot ou Yocto, entre autres ;
2. PAM est désactivé, ce qui est le cas par défaut dans le paquet openssh-server d'Alpine ;
3. l'authentification SSH par mot de passe est activée ;
4. au moins un compte a un astérisque comme empreinte ;
5. un autre compte a une empreinte valide. Alpine précise : une empreinte $5$ ou $6$, c'est-à-dire SHA-256 ou SHA-512 crypt.

Alpine cite parmi les comptes * concernés : root, un utilisateur créé avec adduser sans mot de passe, l'utilisateur alpine des images officielles tiny-cloud, ou un utilisateur issu d'un annuaire via musl-nscd. Le chercheur signale que les images cloud officielles d'Alpine pour AWS et Azure contiennent un compte alpine concerné par défaut, avec des privilèges doas sans mot de passe, ce qui pourrait mener à un accès root.

Pour une équipe technique, trois familles de systèmes méritent une vérification :

• les serveurs et machines virtuelles Alpine, en particulier ceux construits depuis les images cloud officielles ;
• les conteneurs Alpine qui embarquent un serveur SSH : c'est moins courant, mais on le trouve dans des bastions, des environnements de développement ou des outils internes ;
• les équipements embarqués construits avec Buildroot, Yocto ou OpenWrt : routeurs, passerelles, boîtiers industriels, appliances. Ce sont souvent les plus difficiles à inventorier et à mettre à jour.

Se protéger : contrôles concrets

1. Mettre à jour et redémarrer

Le correctif est OpenSSH 10.6p2. Sur Alpine, BleepingComputer indique la commande apk upgrade openssh. Alpine insiste sur le redémarrage de sshd : tant que le démon en cours d'exécution n'est pas remplacé, l'ancien code reste actif.

Pour les équipements embarqués, la mise à jour passe par le firmware du fabricant. Demandez-lui explicitement si ses versions intègrent OpenSSH avec musl et sans PAM, et à quelle date un firmware corrigé sera disponible.

2. Désactiver l'authentification SSH par mot de passe

C'est la mesure de contournement indiquée par les sources : PasswordAuthentication no dans la configuration du serveur SSH, puis redémarrage. Au-delà de cette faille, c'est une bonne pratique générale pour tout serveur accessible depuis Internet : l'authentification par clé, ou par certificat SSH, supprime toute une classe d'attaques.

3. Chercher des traces d'exploitation

Le chercheur propose une méthode simple sur Alpine :

• chercher les connexions SSH réussies par mot de passe dans les journaux, par exemple avec grep "Accepted password" /var/log/messages ;
• pour chaque compte concerné, vérifier son champ dans /etc/shadow (par exemple grep '^alpine:' /etc/shadow) ;
• si le champ contient * alors que les journaux montrent une connexion réussie par mot de passe, c'est un indice d'exploitation.

En bonne pratique, faites cette recherche sur vos journaux centralisés plutôt que sur la machine seule : un attaquant qui a obtenu un accès root peut effacer les journaux locaux.

4. Inventorier là où vous ne regardez pas d'habitude

Le scanner de vulnérabilités ne voit souvent que les serveurs. Trois questions permettent d'élargir l'inventaire :

• quelles images de base utilisez-vous ? Cherchez dans vos Dockerfiles, vos modèles d'images (Packer, images de VM) et vos registres les images alpine qui installent openssh-server ;
• quels équipements exposent le port 22 ? Un scan de votre surface externe, puis interne, liste les services SSH et, souvent, leur bannière de version ;
• quels produits tiers embarquent OpenSSH ? Une SBOM (Software Bill of Materials, la liste des composants logiciels d'un produit) fournie par le fabricant répond à cette question en quelques minutes. Sans SBOM, il faut demander.

5. Ajouter un contrôle dans la chaîne de build

Pour les équipes qui produisent elles-mêmes des images ou des firmwares, deux contrôles automatiques évitent de redécouvrir le problème à la prochaine faille :

• un scan de composants (SCA, Software Composition Analysis) sur chaque image construite, qui bloque la publication si une version d'OpenSSH antérieure à 10.6p2 est détectée sur une base musl ;
• un test de configuration qui échoue si PasswordAuthentication n'est pas explicitement à no dans les images destinées à la production.

Méthode de vérification. Prenez trois systèmes représentatifs : une VM Alpine, une image de conteneur, un équipement embarqué. Pour chacun, répondez par écrit à quatre questions : version d'OpenSSH, présence de PAM, état de PasswordAuthentication, comptes avec * dans /etc/shadow. Si l'une des réponses demande plus d'une heure pour être obtenue, c'est votre inventaire qu'il faut traiter en priorité, pas seulement cette faille.

Ce que cette affaire dit du rythme des correctifs

Le message de l'équipe OpenSSH est le point le plus utile pour la suite. Elle justifie la publication immédiate par la redécouverte rapide de bugs par des agents d'IA, et le chercheur a lui-même trouvé SSHole avec des agents. Notre lecture, qui reste une hypothèse : le temps entre la publication d'un correctif et les premières tentatives d'exploitation risque de continuer à se réduire. Un processus qui applique les correctifs critiques à la fenêtre de maintenance mensuelle prend du retard sur ce rythme. Prévoyez une voie rapide, documentée et testée, pour les correctifs d'authentification sur les services exposés.

FAQ

Mon serveur Ubuntu ou Debian est-il vulnérable à SSHole ?

Non, selon BleepingComputer : les systèmes basés sur glibc, dont Debian, Ubuntu et Fedora, ne sont pas vulnérables, de même que ceux qui utilisent PAM. La faille ne concerne que les systèmes musl réunissant les conditions décrites plus haut.

Quelle version d'OpenSSH corrige CVE-2026-123158 ?

OpenSSH 10.6p2. Sur Alpine, la mise à jour se fait avec apk upgrade openssh, suivie d'un redémarrage de sshd pour remplacer le démon en cours d'exécution.

Désactiver le mot de passe sur un compte suffit-il à le protéger ?

Pas sur un système touché : c'est précisément l'astérisque qui bloque normalement le mot de passe qui est contourné. La protection efficace en attendant le correctif est de désactiver l'authentification par mot de passe au niveau du serveur SSH (PasswordAuthentication no).

Comment savoir si SSHole a été exploitée chez moi ?

Cherchez dans les journaux SSH les connexions réussies par mot de passe, puis vérifiez si le compte concerné a un dans /etc/shadow. Une connexion par mot de passe réussie sur un compte marqué est un indice d'exploitation.

Sources

• BleepingComputer, OpenSSH flaw lets attackers log into password-disabled Linux accounts, 5 novembre 2026 : https://www.bleepingcomputer.com/news/security/openssh-flaw-lets-attackers-log-into-password-disabled-linux-accounts
• SecurityWeek, OpenSSH Rushes Patches for 'SSHole' Authentication Bypass, 6 novembre 2026 : https://www.securityweek.com/openssh-rushes-patches-for-sshole-authentication-bypass
• Ars Technica, Meet \sshole, the vulnerability that lets hackers SSH into Linux devices*, novembre 2026 : https://arstechnica.com/security/2026/11/vulnerability-allows-attackers-to-log-into-some-linux-devices-sans-password

---

Pour mettre en place une voie rapide de correctifs et un inventaire des images et équipements qui embarquent vos composants, WeeSec accompagne les équipes techniques sur le DevSecOps.