sshole : faille d'OpenSSH sur Alpine, mettez à jour

Le 5 novembre, le projet OpenSSH a publié la version 10.6p2 pour corriger CVE-2026-123158, surnommée « sshole ». La faille permet de se connecter en SSH sans connaître le mot de passe sur les systèmes Linux compilés avec la bibliothèque musl et sans PAM, c'est-à-dire exactement la configuration par défaut d'Alpine Linux. Elle obtient un score CVSS 3.1 de 8,1 (élevé) et des preuves de concept publiques existent déjà.

Précisons d'emblée la portée : Debian, Ubuntu, Fedora et les autres distributions basées sur glibc ne sont pas concernées, pas plus que les systèmes qui vérifient les mots de passe via PAM, Dropbear ou OpenBSD. Mais Alpine sert de base à un très grand nombre d'images Docker, de routeurs et d'appareils embarqués : le nombre de machines exposées est loin d'être négligeable.

Ce qui s'est passé

5 novembre : Damien Miller annonce OpenSSH 10.6p2 sur la liste oss-security avec un « contournement de sécurité critique » pour les systèmes Linux utilisant musl avec PAM désactivé. La faille a été découverte par Özgün Kültekin, de Wakefield.
5 novembre : Alpine publie des paquets corrigés pour toutes ses branches maintenues, de la 3.16 à edge, et les détails techniques sont rendus publics.
6 novembre : le GovCERT de Hong Kong émet une alerte de menace élevée et indique que du code de preuve de concept circule déjà.

Comment ça marche

Sous Linux, les comptes qui ne doivent jamais accepter de mot de passe (par exemple un utilisateur qui se connecte uniquement par clé SSH) ont généralement un * dans le champ du mot de passe de /etc/shadow. Lorsque la fonction crypt() de musl reçoit un mot de passe de plus de 256 octets, elle le refuse en renvoyant… *. Le chemin sans PAM d'OpenSSH comparait ce résultat à ce qui est stocké dans /etc/shadow, et comme les deux valent *, il acceptait le mot de passe.

Résultat : n'importe quel mot de passe de plus de 256 caractères ouvre la porte des comptes « sans mot de passe ». L'équipe d'OpenSSH estime que la cause profonde se situe hors de sshd, mais comme la faille s'exploite à travers lui, elle l'a corrigée là : la version 10.6p2 rejette les hachages stockés trop courts pour être valides.

Qui est concerné

D'après les analyses d'OX Security, de SAFE Security et de Help Net Security, une machine n'est vulnérable que si toutes ces conditions sont réunies :

OpenSSH antérieur à 10.6p2 compilé avec musl (Alpine, OpenWrt, Buildroot, Yocto et de nombreuses images Docker).
Pas de PAM (le paquet openssh-server d'Alpine ne l'utilise pas par défaut) et l'authentification par mot de passe activée, ce qui est le réglage par défaut d'OpenSSH.
Un compte avec * comme mot de passe et, en plus, un autre compte local doté d'un vrai mot de passe.

Les comptes à risque sont ceux qui ne devraient « jamais » accepter de mot de passe : utilisateurs de déploiement par clé uniquement, utilisateurs LDAP ou root lui-même, qui a * sur Alpine depuis la 3.16 (même si le réglage par défaut PermitRootLogin bloque la connexion root s'il n'a pas été modifié). Le cas le plus sensible concerne les images officielles d'Alpine pour AWS et Azure, dont l'utilisateur alpine peut lancer doas sans mot de passe : sur un système vulnérable, cela équivaut à un accès administrateur. Les comptes verrouillés avec ! au lieu de * ne sont pas concernés.

Est-elle exploitée ?

Les sources divergent, mieux vaut donc se méfier des gros titres. Previdian affirme avoir détecté des tentatives moins de neuf heures après la divulgation et qu'un attaquant a obtenu un accès root sur l'un de ses leurres Alpine. SAFE Security indiquait au contraire le 6 novembre que l'exploitation réelle n'avait pas été confirmée, et la CISA ne l'a pas encore ajoutée à son catalogue des vulnérabilités exploitées. Plusieurs sources confirment en revanche la présence de preuves de concept sur GitHub ; Previdian prévient qu'elles ne sont pas vérifiées et pourraient contenir du code malveillant : ne les exécutez pas.

Que faire dès maintenant

Mettre à jour : sur Alpine, apk upgrade -U -a puis rc-service sshd restart. L'installation du paquet ne redémarre pas le sshd en cours ; sans redémarrage, vous restez vulnérable.
Vérifier la version du paquet : corrigée à partir de 10.6_p2-r0 (edge), 10.3_p1-r2 (3.24), 10.2_p1-r1 (3.23), 10.0_p1-r11 (3.22), 9.9_p2-r1 (3.21), 9.7_p1-r6 (3.20) et 9.6_p1-r3 (3.19).
Si la mise à jour n'est pas encore possible : désactivez l'authentification par mot de passe. C'est la mesure recommandée à la fois par l'avis d'oss-security et par Damien Miller lui-même : echo "PasswordAuthentication no" > /etc/ssh/sshd_config.d/00-no-passwords.conf, vérifiez la configuration avec sshd -t et redémarrez sshd.
Reconstruire les images Docker : un conteneur basé sur une ancienne image Alpine avec SSH ne se corrige pas tout seul. Il faut le reconstruire sur l'image mise à jour.
Examiner les journaux : cherchez les lignes Accepted password for dans /var/log/messages pour des comptes qui ne devraient pas avoir de mot de passe. Toute occurrence doit être traitée comme une compromission.
Ne pas exposer SSH à Internet sans nécessité : mieux vaut le placer derrière un VPN ou le restreindre par pare-feu aux réseaux d'administration.

Ce qu'il faut surveiller ensuite

L'ajout éventuel au catalogue KEV de la CISA, qui confirmerait l'exploitation réelle.
Les mises à jour des images Docker, des firmwares de routeurs et des appareils embarqués basés sur musl, souvent plus lentes que celles des distributions.
La fiche définitive du NVD, toujours en attente d'analyse.

Ce n'est pas la seule alerte récente pour les serveurs web : relisez PHP2Shell, les deux failles critiques du cœur de PHP.

Conclusion : sshole n'est pas une faille universelle de SSH, mais sur Alpine elle ne souffre aucun délai : un mot de passe long suffit pour entrer dans des comptes censés être fermés. Mettre à jour, redémarrer sshd et, mieux encore, n'autoriser que les connexions par clé règle le problème.

« sshole » : une faille d'OpenSSH permet d'entrer en SSH avec n'importe quel mot de passe long sur Alpine Linux