Une faille dans OpenSSH permet aux pirates de se connecter à des comptes Linux dont le mot de passe est désactivé, simplement en saisissant un mot de passe de plus de 256 octets

Une vulnérabilité critique affectant les serveurs OpenSSH sur les systèmes Linux compilés avec la bibliothèque C « musl » au lieu de « glibc » permet à des attaquants distants de contourner facilement l'authentification et d'accéder à des comptes sur lesquels l'authentification par mot de passe devrait être désactivée. Ce bug, surnommé *SSHole et référencé sous le numéro CVE-2026-123158, a été découvert par Ozgun Kultekin, chercheur chez Wakefield, et existe depuis dix ans. Il touche la distribution Linux légère Alpine, largement utilisée pour les images de conteneurs Docker dans le cloud. « Sur les systèmes concernés, l'exploit est d'une simplicité déconcertante : il suffit d'envoyer un mot de passe comportant entre 257 et 1 024 caractères », a déclaré Jake Knott, de watchTowr. Les responsables d'OpenSSH ont réagi rapidement en ajoutant une mesure d'atténuation dans la mise à jour d'urgence OpenSSH 10.6p2.

OpenSSH (également connu sous le nom d'OpenBSD Secure Shell) est une suite d'utilitaires réseau sécurisés basée sur le protocole Secure Shell (SSH), qui fournit un canal sécurisé sur un réseau non sécurisé dans une architecture client-serveur. OpenSSH a vu le jour sous la forme d'un fork du programme libre SSH développé par Tatu Ylönen ; les versions ultérieures du SSH de Ylönen étaient des logiciels propriétaires proposés par SSH Communications Security. OpenSSH a été publié pour la première fois en 1999 et est actuellement développé dans le cadre du système d'exploitation OpenBSD.

Une vulnérabilité critique affectant les serveurs OpenSSH sur les systèmes Linux compilés avec la bibliothèque C « musl » au lieu de « glibc » permet à des attaquants distants de contourner facilement l’authentification et d’accéder à des comptes sur lesquels l’authentification par mot de passe devrait être désactivée. Cette faille touche la distribution Linux légère Alpine, largement utilisée pour les images de conteneurs Docker dans le cloud, ainsi que les distributions Linux destinées aux systèmes embarqués.

Ce bug de sécurité, surnommé *SSHole et référencé sous le numéro CVE-2026-123158, a été découvert par Ozgun Kultekin, chercheur au sein de la société de tests de sécurité Wakefield, et existe depuis dix ans. Les responsables d’OpenSSH ont réagi rapidement en ajoutant une mesure d’atténuation pour cette faille dans la mise à jour d’urgence OpenSSH 10.6p2 publiée récemment, même s’ils affirment que le bug ne se trouve pas réellement dans leur code.

« Ce n’est pas tous les jours que l’« exploit » d’une vulnérabilité dans une technologie aussi répandue qu’OpenSSH consiste simplement à « envoyer un mot de passe long » ou à « envoyer beaucoup de caractères A », mais c’est pourtant le cas », a déclaré Jake Knott, responsable du renseignement sur les menaces chez watchTowr, une société spécialisée dans la gestion préventive des expositions. « Sur les systèmes concernés, l’exploit est d’une simplicité déconcertante : il suffit d’envoyer un mot de passe comportant entre 257 et 1 024 caractères. »

Heureusement, cette faille ne peut fonctionner que si certaines conditions sont réunies :

• La distribution Linux doit utiliser musl, ce qui signifie que de nombreuses distributions serveur courantes, telles que Debian, Ubuntu et Fedora, ne sont pas concernées
  
• Le système doit utiliser OpenSSH et non d’autres implémentations de serveur SSH telles que Dropbear, que de nombreuses distributions embarquées utilisent
  
• OpenSSH doit être configuré sans prise en charge des modules d’authentification enfichables (PAM), le framework de connexion Linux le plus courant
  
• OpenSSH doit autoriser l’authentification par mot de passe
  
• L’attaquant doit connaître le nom d’un compte pour lequel la connexion par mot de passe a été désactivée au niveau du système

Ces conditions sont remplies dans la configuration par défaut d’Alpine Linux et de son nom d’utilisateur intégré « alpine », ce qui permet d’exécuter des commandes en tant que root. Le projet Alpine a publié des mises à jour d’urgence pour le paquet openssh et recommande aux utilisateurs qui ne peuvent pas effectuer la mise à jour de désactiver l’authentification par mot de passe dans la configuration d’OpenSSH et de configurer l’authentification par clé.

Pourquoi cette attaque basique parvient-elle à fonctionner ?

Cette faille résulte de trois modifications apportées à plusieurs années d’intervalle, chacune visant à résoudre un problème différent. En 2012, les développeurs de musl ont limité la longueur des mots de passe à 256 octets afin d’empêcher les attaquants de monopoliser les ressources du serveur en envoyant de longs mots de passe devant être hachés dans le cadre du processus de vérification de connexion.

Parallèlement, ils ont également fait en sorte que la fonction de hachage des mots de passe de la bibliothèque renvoie un astérisque (*) en cas d’échec. Cet astérisque est le même caractère qu’Unix utilise depuis les années 1980 pour marquer les comptes pour lesquels aucun mot de passe ne doit jamais correspondre — c’est-à-dire les comptes dont le mot de passe est désactivé au niveau du système.

En 2016, OpenSSH a modifié la manière dont il vérifie les mots de passe pour les comptes dont le champ de mot de passe ne fournit pas de sel pour le hachage, en empruntant le sel d’un autre compte afin d’empêcher les attaquants de deviner les noms d’utilisateur existants par des tentatives de connexion par force brute et en chronométrant les réponses du serveur. Puis, en 2022, Alpine a remplacé le champ de mot de passe de l’utilisateur root par un astérisque afin que les connexions par clé SSH continuent de fonctionner pour ce compte.

Lorsqu’un attaquant envoie un mot de passe trop long pour un compte dont le mot de passe est désactivé sur un tel système, la tentative de hachage échoue et renvoie un astérisque, que sshd compare à l’astérisque stocké dans le champ « mot de passe » du compte. Les deux correspondent, et la connexion aboutit.

Les images cloud d’Alpine Linux constitueront la cible principale

Le paquet OpenSSH standard d’Alpine est compilé sans PAM, et les connexions par mot de passe sont activées par défaut ; les serveurs Alpine remplissent donc les conditions dès leur installation. Sur les images cloud officielles publiées entre les versions 3.18.11 et 3.24.3, le compte utilisateur par défaut, nommé « alpine », fait partie des comptes dont le mot de passe est désactivé, et les images lui accordent des privilèges « doas » sans mot de passe.

Par conséquent, un attaquant qui se connecte en tant que cet utilisateur peut ensuite passer au compte root ; les images sont donc exposées dès qu’un administrateur définit un mot de passe pour n’importe quel autre compte du système, car l’existence d’un compte légitime doté d’un vrai mot de passe est nécessaire pour que cette attaque fonctionne. Contrairement à la faille critique « regreSSHion » de 2024, celle-ci se limite à l’environnement musl, mais ne nécessite aucune ingénierie d’exploitation particulière.

« Les serveurs SSH exposés à Internet sont déjà soumis 24 heures sur 24 à des tentatives de deviner les mots de passe et à des attaques par force brute », a déclaré Knott. « Exploiter cette vulnérabilité signifie simplement que ces mêmes attaquants ajoutent une tentative de mot de passe très long à cette liste d’attaques par force brute. Nous serions extrêmement surpris de ne pas voir des attaquants utilisant des outils de force brute SSH tenter cette attaque d’ici le week-end. »

Les organisations doivent également vérifier si cette faille a déjà été exploitée contre leurs serveurs. La présence d’une entrée « Accepted password » dans le fichier /var/log/messages pour un compte ne disposant pas de mot de passe, tel que root, un utilisateur utilisant uniquement une clé ou l’utilisateur par défaut « alpine », constitue un signe fort de compromission. Alpine recommande de vérifier l’utilisation de doas, les utilisateurs et fichiers récemment créés sur les machines exposées, et précise dans son avis que tout serveur pour lequel une connexion ne peut être exclue doit être considéré comme compromis. Kultekin a également publié sur GitHub un script de vérification qui identifie les serveurs exposés et répertorie les comptes à risque.

En juin 2026, des chercheurs en sécurité publièrent un exploit détaillé et fonctionnel pour une faille de type « use-after-free » du noyau Linux qui permettait à un utilisateur local non privilégié d'élever ses privilèges au niveau root et de s'échapper d'un conteneur. La faille, CVE-2026-23111, se trouvait dans le code de filtrage de paquets nf_tables du noyau et avait été corrigée en amont le 5 février 2026.

Sources : *sshole ; NIST (NVD)

Et vous ?

Pensez-vous que cette information est crédible ou pertinente ?
Quel est votre avis sur le sujet ?

Voir aussi :

Une faille de sécurité "critique" a été découverte dans OpenSSH, elle affecte la quasi-totalité des systèmes Linux et 14 millions de serveurs connectés à internet sont vulnérables, d'après Qualys

La suite d'utilitaires réseau sécurisés OpenSSH 10.4 est disponible, avec la prise en charge des signatures post-quantiques composites et des corrections de plusieurs failles de sécurité

Une faille d'exécution de code dans le firmware UEFI menace la plupart des fournisseurs de serveurs et des centres de données à l'échelle mondiale, la vulnérabilité a un niveau de gravité de 9,5 sur 10