OpenSSH corrige en urgence *sshole : un mot de passe trop long ouvre les comptes verrouillés d'Alpine Linux

Le message du mainteneur OpenSSH Damien Miller ne cherchait pas la nuance. Si vous opérez un système Linux qui utilise musl libc sans PAM, Alpine Linux en est un exemple, arrêtez de lire et positionnez PasswordAuthentication=no ou désactivez SSH immédiatement. La formulation accompagnait la sortie d'OpenSSH Portable 10.6p2, le 5 novembre 2026, et Alpine a publié le même jour ses paquets openssh corrigés pour toutes les branches supportées, de 3.16 à edge, plus plusieurs branches plus anciennes.

La faille, référencée CVE-2026-123158, porte un surnom que personne chez OpenSSH n'a essayé d'adoucir : *sshole. L'astérisque n'est pas décoratif. Il désigne précisément la valeur de retour qui casse le mécanisme.

Le scénario est le suivant : quand sshd vérifie lui-même les mots de passe, sans passer par PAM, un mot de passe compris entre 257 et 1 024 octets fait échouer la fonction crypt() de musl, qui renvoie la chaîne "". OpenSSH compare ensuite cette valeur au hash stocké du compte. Or les comptes verrouillés ou sans mot de passe stockent justement "" ou "!" dans /etc/shadow. Deux manières différentes de dire "aucune correspondance" finissent par correspondre. L'attaquant est authentifié sur un compte qui n'aurait jamais dû accepter de mot de passe.

Sur une installation Alpine par défaut, cela signifie un accès root depuis une seule connexion. Les comptes exposés incluent root sur Alpine 3.16 et au-delà, les utilisateurs service et deploy réservés aux clés, les utilisateurs d'annuaire via nslcd, winbind ou sssd, et surtout le compte alpine des images tiny-cloud, qui dispose d'un accès doas sans mot de passe, autrement dit root de fait. Les images cloud officielles d'Alpine sur AWS et Azure embarquent ce compte.

La découverte revient à Özgün Kültekin, de Wakefield, qui l'a signalée à OpenSSH. Kültekin indique avoir trouvé la vulnérabilité à l'aide d'agents IA ayant exécuté environ 17 600 tests d'authentification combinant différentes configurations OpenSSH, des hash de mots de passe malformés et des mots de passe surdimensionnés. Une méthode de fuzzing pilotée par agents qui a mis au jour un bug resté en place pendant une décennie.

Neuf heures

Help Net Security rapporte que l'exploitation de *sshole a commencé dans les neuf heures suivant la divulgation. Un accès root a été confirmé sur un honeypot Alpine Linux. GreyNoise a observé du scanning, des tentatives d'exploitation et des exploitations réussies, avec un premier relevé daté du 5 novembre à 18h3x UTC. L'argument commercial du bug, tel que résumé par l'équipe Alpine : une connexion, ça marche à chaque fois, et aucune nouvelle tentative n'est nécessaire.

Le périmètre reste étroit, et c'est ce qui sépare un incident gérable d'une panique injustifiée. La vulnérabilité n'existe pas sur les systèmes non-Linux, ni sur les systèmes Linux/glibc, ni sur les systèmes Linux qui utilisent PAM pour l'authentification par mot de passe. Les systèmes utilisant openssh-server-pam avec UsePAM yes ne sont pas affectés. La condition déterminante est l'empilement musl + absence de PAM + authentification par mot de passe activée, qui se trouve être la configuration par défaut du paquet openssh-server d'Alpine.

Aucun identifiant CVE n'était attribué au moment où Alpine a publié son avis ; CVE-2026-123158 a suivi. Au 9 novembre, la faille n'apparaissait pas encore dans le catalogue CISA KEV, alors que des exploitations réussies étaient déjà documentées sur le terrain. Les deux calendriers ne sont pas synchronisés.

Un détail que la discussion sur LWN remonte : Dropbear, l'implémentation SSH légère très répandue sur les équipements embarqués, plafonne tous les mots de passe à 100 caractères, ce qui le met hors d'atteinte du déclencheur "mot de passe très long". Mais Dropbear utilise lui aussi un simple test NULL sur la valeur de retour, qui ne repère pas l'astérisque. La même classe d'erreur existe ailleurs que dans OpenSSH.

La correction dans 10.6p2 est décrite comme un contournement plutôt que comme une refonte de la vérification de mot de passe. Pour les DSI qui gèrent des flottes de conteneurs basés sur Alpine, images de base parmi les plus téléchargées de l'écosystème Docker, la question opérationnelle n'est pas de savoir si un serveur SSH tourne sur l'image en production, c'est de savoir lesquelles des images dérivées, plugins et appliances embarquent openssh-server sans PAM. Home Assistant OS, construit sur Alpine, n'installe pas SSH par défaut, mais son plugin Terminal & SSH très utilisé était vulnérable ; un correctif est sorti.

La mitigation immédiate tient en deux lignes : PasswordAuthentication no dans /etc/ssh/sshd_config, puis redémarrage de sshd. Pour détecter une compromission passée sur Alpine, les avis pointent vers l'examen des logs d'authentification à la recherche de connexions par mot de passe réussies sur des comptes censés être en clé seule.