N'importe quel mot de passe assez long ouvre certains serveurs OpenSSH sous Alpine Linux

Un premier essai raté, puis un mot de passe de plus de 256 caractères (et de moins de 1 024), peu importe ce qu'il contient. Sur certains serveurs Linux, cela suffit pour ouvrir une session à distance sur un compte… qui n'a pas de mot de passe. Le projet OpenSSH, le logiciel de connexion à distance sécurisée (SSH) le plus répandu, a corrigé cette faille le 5 novembre dans sa version 10.6p2, destinée à Linux et aux autres systèmes.

Le même jour, le CERT-FR, le centre gouvernemental de veille et d'alerte rattaché à l'ANSSI, a publié une alerte (CERTFR-2026-ALE-015). Elle concerne les systèmes Linux qui utilisent la bibliothèque C musl et dont le serveur SSH fonctionne sans PAM, le mécanisme d'authentification habituel de Linux. « Lorsque les conditions sont réunies, cette vulnérabilité est triviale à exploiter », prévient le CERT-FR, qui liste comme vulnérables les versions d'OpenSSH antérieures à la 10.6p2. Un identifiant a été attribué le même jour, CVE-2026-123158, et des preuves de concept sont publiques. Ni le CERT-FR ni l'éditeur ne font état d'une exploitation à ce stade.

Trois choix anodins faits entre 2012 et 2016

La faille a été découverte par Özgün Kültekin, de la société Wakefield, qui la détaille sur un site baptisé « sshole ». Elle naît de la rencontre de trois choix techniques. En 2012, musl modifie sa fonction crypt(), qui calcule l'empreinte d'un mot de passe : en cas d'échec, elle renvoie désormais le caractère * au lieu d'une valeur vide. La même année, musl plafonne à 256 octets les mots de passe traités par son algorithme SHA-512. Au-delà, le calcul échoue… et renvoie donc *.

En 2016, OpenSSH modifie à son tour son code pour ne plus révéler quels comptes existent : pour un utilisateur inconnu ou un compte sans mot de passe, il emprunte le « sel », une valeur aléatoire qui sert au calcul de l'empreinte, à un autre compte. Or, sous Linux, un compte sans mot de passe, comme un compte réservé aux clés SSH, peut justement porter un * dans le fichier /etc/shadow. Avec un mot de passe trop long, l'empreinte calculée vaut *, exactement comme la valeur enregistrée, et la connexion est acceptée. OpenSSH considère que la cause profonde se trouve hors de son serveur, mais qu'il peut l'éviter de son côté. Il qualifie sa modification de « contournement de sécurité critique ».

Qui est vraiment exposé ?

Les conditions sont nombreuses, mais elles correspondent souvent aux réglages par défaut. Selon le chercheur, il faut réunir :

• un système bâti sur musl : Alpine Linux, Buildroot, Yocto, ou une image Docker dérivée d'Alpine qui fait tourner un serveur OpenSSH. OpenWrt, dont le serveur SSH par défaut est Dropbear, n'est concerné que si OpenSSH y a été installé ;
• un serveur SSH sans PAM, ce qui est le cas par défaut du paquet openssh-server d'Alpine, ou de toute configuration en UsePAM no ;
• l'authentification par mot de passe activée, qui est le réglage par défaut ;
• un compte sans mot de passe, marqué par un * (utilisateur qui ne se connecte que par clé, compte LDAP, ou compte root sur Alpine), et au moins un autre compte doté d'un vrai mot de passe.

Le chercheur signale un cas qui pourrait être grave : selon lui, les images officielles d'Alpine pour AWS et Azure créent un utilisateur alpine qui peut passer administrateur sans mot de passe, si bien qu'une connexion frauduleuse reviendrait à un accès root. Toujours d'après lui, les distributions fondées sur la bibliothèque glibc (Debian, Ubuntu, Red Hat…), les systèmes qui utilisent PAM, le serveur Dropbear et OpenBSD ne sont pas concernés.

Que faire dès maintenant ?

Aucun outil de piratage n'est nécessaire : un texte trop long collé dans l'invite de mot de passe, après un premier essai raté, pourrait suffire. Les parades sont simples.

• Mettre à jour OpenSSH en version 10.6p2, ou installer la version corrigée fournie par votre distribution. Chez Alpine, le paquet openssh-server 10.6_p2-r0 est disponible depuis le 5 novembre sur la branche de développement « edge ». Alpine a aussi publié le 5 novembre des versions corrigées pour ses branches stables, de la 3.16 à la 3.24 (par exemple 10.3_p1-r2 en 3.24) ; redémarrez ensuite sshd, que la mise à jour ne relance pas.
• En attendant, désactiver l'authentification par mot de passe : ajoutez PasswordAuthentication no à la configuration du serveur SSH, puis redémarrez le service. C'est la solution que privilégie le CERT-FR ; à défaut, il conseille de couper le service SSH.
• Chercher des traces : le CERT-FR relaie la recommandation du chercheur : rechercher dans les journaux d'authentification les connexions réussies à des comptes dont le mot de passe est désactivé (* dans /etc/shadow). Le chercheur publie aussi un outil de vérification sur GitHub.
• Faire l'inventaire des boîtiers embarqués et des conteneurs bâtis sur musl : ce sont souvent les équipements qu'on met à jour le moins.

Une question reste ouverte : quelqu'un a-t-il déjà emprunté cette porte ? « Pour autant qu'on sache, personne ne l'avait remarqué », écrit Özgün Kültekin, qui fait remonter le problème à 2016. Pour en avoir le cœur net, il faudra relire les journaux de connexion de vos serveurs.

Mise à jour du 12 novembre 2026

La faille d'OpenSSH qui permet d'ouvrir, avec un mot de passe trop long, des comptes censés refuser toute connexion par mot de passe sur les Linux bâtis sur la bibliothèque musl, comme Alpine (CVE-2026-123158, surnommée « SSHole »), est désormais exploitée. Le 9 novembre, l'agence américaine de cybersécurité CISA l'a inscrite dans son catalogue des vulnérabilités activement exploitées. Les administrations fédérales civiles américaines ont jusqu'à ce jeudi 12 novembre pour corriger.

Selon le SANS Internet Storm Center, ses pots de miel, de faux serveurs destinés à attirer les attaques, ont reçu une première tentative d'exploitation dès le 5 novembre, avec un mot de passe composé uniquement de la lettre « A ». D'après BleepingComputer, la société GreyNoise, qui observe le trafic malveillant sur Internet, a constaté une première intrusion réussie le 7 novembre. Au 9 novembre, elle avait relevé 16 attaques réussies sur les réseaux qu'elle surveille, menées depuis six adresses IP ; son suivi public en recense 40, depuis dix adresses IP, au 12 novembre. Les attaquants ont tenté de lire les empreintes de mots de passe et les clés SSH de root, et de modifier la liste des clés autorisées. L'un d'eux a obtenu les droits d'administrateur (« root ») et installé TAC Agent, un programme de contrôle à distance écrit en Python. GreyNoise précise que ces attaques ne sont pas représentatives de l'ensemble de l'activité liée à la faille.

La consigne ne change pas : installer OpenSSH 10.6p2 ou le paquet corrigé de sa distribution, ou à défaut désactiver l'authentification par mot de passe. Sur un serveur resté exposé, BleepingComputer conseille aussi de rechercher les connexions par mot de passe inattendues sur les comptes dont le champ du fichier /etc/shadow vaut « * », les clés SSH ajoutées sans autorisation et les fichiers ou services de démarrage de TAC Agent.