Une vulnérabilité de sécurité particulièrement préoccupante vient d’être corrigée dans OpenSSH. Baptisée « *sshole » et référencée CVE-2026-123158, elle permet, dans certaines configurations, d’ouvrir une session SSH sans connaître le mot de passe du compte ciblé. Le correctif a été publié le 5 novembre 2026, tandis que l’ANSSI a diffusé une alerte à destination des administrateurs.
Le problème est aussi ancien que surprenant : une suite de caractères anormalement longue peut être acceptée comme mot de passe par des comptes précisément configurés pour ne pas autoriser ce type de connexion. La vulnérabilité a reçu un score de gravité CVSS 3.1 de 8,1 sur 10.
Un accès SSH sans connaître le moindre mot de passe
OpenSSH est un logiciel très largement utilisé pour administrer à distance des serveurs et d’autres équipements informatiques au moyen de connexions chiffrées. Normalement, un compte qui ne doit accepter que des clés SSH, et non un mot de passe, ne peut pas être ouvert en saisissant un mot de passe arbitraire.
La faille « *sshole » bouleverse cette règle sur certaines machines Linux. Le chercheur Özgün Kültekin, de Wakefield, a découvert qu’un mot de passe de plus de 256 caractères pouvait être considéré comme valide pour un compte dont l’authentification par mot de passe était censée être désactivée. Dans les configurations vulnérables, l’attaque ne nécessite ni de connaître le mot de passe d’un utilisateur ni de multiplier les tentatives.
Le risque est concret : si le service SSH est accessible depuis Internet, une personne non autorisée peut obtenir une session sur le compte concerné. Selon les droits de celui-ci, cette connexion peut aller jusqu’à donner le contrôle complet de la machine.
Pourquoi un mot de passe trop long peut-il fonctionner ?
L’origine du problème se situe à la frontière entre OpenSSH et musl, une bibliothèque système utilisée notamment par Alpine Linux. Sur Linux, un compte qui n’accepte pas de mot de passe peut avoir un astérisque (*) dans le champ correspondant du fichier /etc/shadow. Cet astérisque n’est pas une véritable empreinte cryptographique : aucun mot de passe ne devrait pouvoir lui correspondre.
Or, dans certaines situations, la fonction de vérification crypt() de musl renvoie elle aussi un astérisque lorsqu’elle ne peut pas traiter un mot de passe trop long. Combiné à une logique d’OpenSSH introduite en 2016 pour éviter une autre faiblesse de sécurité, ce comportement peut conduire à comparer deux astérisques et à conclure, à tort, que l’authentification a réussi.
Il ne s’agit donc pas d’une rupture du chiffrement SSH, mais d’une erreur dans le mécanisme de vérification des identifiants. OpenSSH précise d’ailleurs considérer que la cause initiale se situe hors de son propre code, tout en ayant publié un correctif pour empêcher son exploitation au travers de son serveur.
Quels serveurs Linux sont réellement concernés ?
La faille ne concerne pas tous les utilisateurs d’OpenSSH. Elle nécessite la réunion de plusieurs conditions : un système utilisant la bibliothèque musl, un serveur OpenSSH fonctionnant sans PAM, l’authentification SSH par mot de passe activée, au moins un compte dont le champ de mot de passe est exactement « * », et un autre compte local actif possédant une véritable empreinte de mot de passe compatible.
Alpine Linux constitue le cas le mieux documenté, car son paquet openssh-server standard fonctionne sans PAM. D’autres environnements construits avec musl, notamment certaines configurations d’OpenWrt, Buildroot ou Yocto, doivent également être examinés. Cela ne signifie pas que tous leurs appareils soient vulnérables : OpenWrt utilise par exemple généralement Dropbear plutôt qu’OpenSSH par défaut.
À l’inverse, les installations habituelles de Debian, Ubuntu ou Fedora utilisant glibc ne sont pas concernées par ce scénario. Les serveurs qui désactivent l’authentification SSH par mot de passe, les systèmes utilisant PAM et les conteneurs qui n’exécutent aucun serveur SSH ne sont pas exposés à cette faille dans les conditions décrites.
Un risque d’accès administrateur sur certaines images cloud
L’un des scénarios les plus sensibles concerne des images officielles Alpine Linux destinées à des environnements cloud, notamment AWS et Azure. Sur certaines versions, un compte « alpine » ne possède pas de mot de passe, mais dispose de droits lui permettant d’exécuter des commandes administrateur sans mot de passe supplémentaire via doas.
Ces images ne sont pas automatiquement vulnérables dès leur premier démarrage. En revanche, si un autre compte local doté d’un véritable mot de passe est ajouté et que les autres conditions sont réunies, un attaquant pourrait se connecter au compte « alpine », puis obtenir les privilèges root.
Le compte root lui-même reste normalement protégé par le réglage SSH par défaut interdisant son ouverture directe par mot de passe ; une configuration autorisant explicitement cette connexion modifie le risque.
Une vulnérabilité présente depuis 2016, découverte avec l’aide d’agents d’IA
Selon le chercheur, le problème remonte à une modification d’OpenSSH datant de 2016, conçue à l’origine pour limiter l’énumération des comptes utilisateurs. La faiblesse serait ainsi restée présente pendant près de dix ans sans être publiquement identifiée.
Pour la détecter, Özgün Kültekin explique avoir comparé plusieurs compilations d’OpenSSH, avec différentes bibliothèques et configurations d’authentification. Des agents d’intelligence artificielle l’ont aidé à exécuter environ 17 600 essais inhabituels. Une seule combinaison, OpenSSH avec musl et sans PAM, acceptait des connexions que toutes les autres refusaient.
D’après la chronologie publiée par Wakefield, la découverte a été signalée à l’équipe OpenSSH le 3 novembre. Un correctif a été proposé en moins d’une heure, les mainteneurs d’Alpine et de musl ont été avertis le 4 novembre, puis les correctifs et les informations publiques ont été diffusés le 5 novembre.
L’ANSSI publie une alerte et les correctifs sont disponibles
Le CERT-FR, rattaché à l’ANSSI, a publié le 5 novembre l’alerte CERTFR-2026-ALE-015. Il prévient qu’un contournement de l’authentification SSH peut être trivial lorsque la configuration vulnérable est présente et invite les responsables des systèmes à vérifier rapidement leur exposition.
Le projet OpenSSH a publié la version 10.6p2 pour corriger le problème. Alpine Linux a diffusé le même jour des paquets corrigés, y compris pour plusieurs anciennes branches. Il faut donc installer le paquet corrigé fourni par sa distribution, sans supposer qu’un numéro de version inférieur à 10.6p2 signifie nécessairement l’absence de correctif : certaines distributions appliquent des correctifs rétroportés.
Sur Alpine Linux, l’éditeur recommande de mettre à jour OpenSSH puis de redémarrer le service sshd. Le redémarrage est indispensable : la simple installation d’un nouveau paquet ne remplace pas le processus déjà en cours d’exécution.
En attendant une mise à jour, la désactivation de l’authentification SSH par mot de passe constitue une mesure de protection, à condition de vérifier auparavant que l’accès par clé fonctionne.
Comment rechercher d’éventuelles connexions suspectes ?
Les administrateurs doivent examiner les journaux de connexion SSH, notamment les événements « Accepted password » associés à des comptes qui ne devraient jamais accepter de mot de passe. Sur Alpine Linux, ces traces peuvent se trouver dans /var/log/messages.
Il convient aussi de contrôler les ouvertures de session inhabituelles, l’utilisation de doas, les nouveaux comptes et les modifications des clés autorisées.
La présence d’une authentification par mot de passe réussie sur un compte dont le champ /etc/shadow vaut « * » doit être considérée comme un signal d’alerte sérieux. Inversement, l’absence de traces ne garantit pas à elle seule qu’aucune intrusion n’a eu lieu, notamment lorsque la journalisation est incomplète.
Au 6 novembre 2026, les bulletins officiels consultés ne font pas état d’une campagne d’exploitation malveillante confirmée. La disponibilité des détails techniques et la simplicité de l’exploitation dans les configurations concernées justifient toutefois une vérification et une mise à jour rapides.