Alpine Linux : un mot de passe trop long peut ouvrir un serveur SSH non corrigé

Sur certains serveurs Alpine Linux, un mot de passe très long, quel qu’il soit, suffit à ouvrir une session à distance. La faille, référencée CVE-2026-123158, touche SSH, le service qui permet d’administrer une machine depuis un autre ordinateur. Le projet OpenSSH a publié en urgence la version 10.6p2 le 5 novembre 2026, et Alpine a diffusé des paquets corrigés. Les images de la distribution destinées au cloud sont les plus exposées.

Le défaut naît de la rencontre de deux conventions, anodines prises une à une. Sur Linux, un compte sans mot de passe porte un simple astérisque à la place de l’empreinte, la trace mathématique que le système garde du secret. La bibliothèque musl, une boîte à outils de base qu’Alpine utilise au lieu de la glibc, renvoie elle aussi un astérisque quand elle refuse une saisie de plus de 256 octets. OpenSSH compare les deux valeurs, les croit identiques et ouvre la session. Selon Alpine, un mot de passe de 257 à 1024 octets suffit ; la fiche du NIST parle de 256 à 1024 caractères.

Le problème couvait depuis des années. D’après Next, le comportement de musl remonte à 2012. La façon dont OpenSSH traite les comptes sans mot de passe découle, elle, d’un changement de 2016. Le défaut avait même déjà été signalé en 2024. Cette fois, l’alerte est venue d’Özgün Kültekin, de Wakefield. Une parade intégrée à OpenSSH a été proposée moins de 24 heures après réception du signalement.

Nous considérons que la cause profonde de ce bogue se situe en dehors d’OpenSSH lui-même.

Quels serveurs SSH sont exposés

Trois conditions doivent être réunies. D’abord, le service SSH accepte les connexions par mot de passe, ce qui est le réglage par défaut d’OpenSSH. Ensuite, la machine possède au moins un compte sans mot de passe, et au moins un autre qui en a un. Enfin, elle tourne sous un Linux bâti sur musl et privé de PAM, le mécanisme séparé qui gère d’ordinaire la vérification des mots de passe. Damien Miller, développeur d’OpenSSH, précise que la faille épargne les systèmes autres que Linux et ceux qui reposent sur la glibc.

Les images cloud d’Alpine sont les plus exposées. Celles des versions 3.18.11 à 3.24.3 livrent un compte « alpine » sans mot de passe, autorisé à prendre les droits d’administrateur grâce à l’outil doas, sans rien saisir. Elles deviennent vulnérables dès qu’un mot de passe est défini sur un autre compte. Un intrus peut alors s’y connecter, puis devenir root, le maître du système. Les conteneurs Docker sans serveur SSH ne sont pas concernés, pas plus que les machines installées via cloud-init, qui désactive la connexion par mot de passe. Musl équipe aussi des systèmes pour l’embarqué, comme OpenWrt, Buildroot et Yocto.

Une gravité discutée

Les avis divergent sur la gravité. Sur le site du NIST, l’agence américaine qui tient la base des vulnérabilités, la note CVSS, barème usuel de gravité des failles, atteint 8,1 : la faille est classée « élevée », pas « critique ». Les notes de version d’OpenSSH parlent pourtant d’une parade de sécurité critique, et Damien Miller emploie le même mot. Au 6 novembre 2026, aucune exploitation confirmée n’était signalée, d’après la société de sécurité StepSecurity. Des preuves de concept, ces programmes qui démontrent l’attaque, circulent toutefois publiquement : des recherches automatiques de serveurs vulnérables sont à prévoir.

Mettre à jour, puis redémarrer

Le correctif d’OpenSSH refuse désormais toute comparaison avec une empreinte trop courte pour être valide. Chez Alpine, les versions 3.21.10, 3.22.8, 3.23.8 et 3.24.4 contiennent le paquet corrigé, et la distribution en a publié pour chaque branche jusqu’à la 3.16. La 3.21 en profite malgré la fin de son support, le 1er novembre 2026. Installer le paquet ne suffit pas : tant que le service SSH n’a pas redémarré, l’ancienne version continue de tourner. Il faut relancer le service juste après la mise à jour ; sur Alpine, la commande est rc-service sshd restart.

Dans le cloud, chaque instance déjà lancée doit être corrigée : reconstruire les images ne protège pas les machines actives. StepSecurity conseille aussi de refaire les images de conteneurs construites ou figées avant le 5 novembre 2026, quand elles font tourner un serveur SSH. Sur les systèmes pas encore corrigés, Damien Miller demande de couper sans attendre l’authentification par mot de passe, voire SSH. Alpine recommande de vérifier d’abord que la connexion par clé fonctionne, en gardant sa session ouverte. Pour repérer une intrusion, cherchez dans le journal /var/log/messages une connexion acceptée par mot de passe sur un compte qui n’en a pas. Au moindre doute, la machine doit être tenue pour compromise.

Cette version tombe en pleine période chargée pour l’équipe d’OpenSSH. Ses notes de version font état d’un grand nombre de signalements de sécurité, dont beaucoup proviennent de modèles d’intelligence artificielle ou ont été rédigés avec leur aide. Damien Miller explique la publication éclair par des cas de redécouverte rapide de bogues par des agents d’IA, parfois en quelques heures. Le projet promet des versions plus fréquentes pour livrer les corrections sans attendre. Nous avions relevé un phénomène proche lors du report de PostgreSQL 19.

Pour une TPE, une association ou un particulier, le geste est simple. Si vous louez un serveur virtuel sous Alpine, ou si un prestataire en gère un pour vous, vérifiez que la mise à jour d’OpenSSH est installée et que le service a bien redémarré. Sur un routeur ou un boîtier sous OpenWrt, surveillez les mises à jour du projet ou du fabricant. À notre avis, cette faille rappelle un principe de base : sur un serveur ouvert sur Internet, la connexion par clé doit remplacer le mot de passe.