Veille menaces / Faille
« sshole » : OpenSSH sur Alpine Linux accepte n'importe quel mot de passe long pour les comptes verrouillés
Sur les systèmes Linux basés sur musl comme Alpine, OpenSSH sans PAM permettait de se connecter à un compte dont le champ mot de passe vaut « * » avec n'importe quel mot de passe de plus de 256 octets. OpenSSH 10.6p2 et les paquets Alpine l'ont corrigé le 5 novembre. Un chercheur a vu des tentatives en moins de neuf heures, et un accès root sur l'un de ses pots de miel.
- Secteur
- Tous secteurs
- Point d'entrée
- Faille logicielle
- Produit ou fournisseur
- OpenSSH, Alpine Linux
- Comment c'est arrivé
- Quand le mot de passe dépasse 256 octets, la fonction crypt() de musl renvoie « * » comme valeur d'erreur, ce qui correspond au « * » stocké pour un compte verrouillé. Il faut le paquet openssh-server par défaut sans PAM, PasswordAuthentication activé et un compte dont le champ mot de passe vaut « * ». Alpine 3.16 à 3.24 et edge sont concernés ; les autres systèmes musl (OpenWrt, Buildroot, Yocto, de nombreuses images Docker) sont à vérifier. Debian, Ubuntu et Fedora ne sont pas concernés.[1][2][3] Vérifié le 9 nov. 2026
- Ce qui a été volé
- Pas encore public Vérifié le 9 nov. 2026
- Qui est touché
- Pas encore public Vérifié le 9 nov. 2026
- Acteur
- Non attribué
- CVE
- CVE-2026-123158
Chronologie
- Alpine publie son avis et des paquets corrigés pour toutes les branches de 3.16 à edge ; OpenSSH publie la version 10.6p2. La faille a été trouvée par Özgün Kültekin, de Wakefield. La mise à jour ne suffit pas : il faut redémarrer sshd. [2][4]
- Detectify indique n'avoir connaissance d'aucun signalement public d'exploitation à 15 h 30. [2]
- Previdian indique avoir vu une première tentative moins de neuf heures après la publication de la CVE : huit tentatives depuis une seule adresse au Japon, et un accès root confirmé sur l'un de ses pots de miel tournant sous un vrai Alpine avec OpenSSH. La CISA n'a pas ajouté la faille à sa liste KEV. [3]
- GreyNoise enregistre sa première exploitation réussie à 0 h 46 UTC, environ 40 heures après le correctif, puis 16 chaînes d'exploitation réussies contre des réseaux qu'il protège, depuis six adresses. Les attaquants tentent de lire les empreintes de mots de passe et les clés SSH de root et modifient authorized_keys ; l'un d'eux obtient root et installe un agent de contrôle à distance en Python. Aucun groupe n'est nommé. [5]