Faille OpenSSH SSHole (CVE-2026-123158) : êtes-vous concerné et comment vous protéger ?

Une faille d’OpenSSH baptisée « SSHole » permet de se connecter sans le bon mot de passe sur certains serveurs Linux fondés sur Alpine et la bibliothèque musl, d’après Help Net Security. Référencée CVE-2026-123158, elle est corrigée dans OpenSSH 10.6p2, publiée le 5 novembre.

La société Previdian a observé une première tentative d’exploitation moins de neuf heures après la publication de la faille, avec un accès root obtenu sur un serveur piège. Les serveurs Debian, Ubuntu et Fedora, qui s’appuient sur glibc et PAM, ne sont pas concernés.

Prudence toutefois : les conditions exactes varient légèrement selon les analyses, et nous n’avons pas pu lire l’avis officiel d’Alpine. Les commandes ci-dessous sont relevées dans des guides de sécurité, non testées par nos soins.

Qui est concerné

Le problème naît de la rencontre entre OpenSSH et musl. Selon Cycode et Ostorlab, quatre conditions doivent être réunies : un sshd lié à musl et compilé sans PAM (c’est le cas du paquet Alpine « openssh-server »), l’authentification par mot de passe activée (réglage par défaut), un compte dont le champ de mot de passe dans /etc/shadow vaut « * », et un autre compte dont le hash commence par $5$ ou $6$.

Les comptes à clé seule créés sans mot de passe, certains comptes d’annuaire et le compte root des images Alpine récentes sont dans ce cas. L’attaquant envoie un mot de passe de 257 à 1 024 octets. Root reste protégé par défaut par PermitRootLogin prohibit-password, mais un compte intermédiaire avec doas sans mot de passe, comme l’utilisateur « alpine » des images cloud, ouvre la voie, selon Help Net Security. D’autres systèmes musl (OpenWrt, Buildroot, Yocto) et des firmwares embarqués peuvent aussi être touchés.

Vérifier votre configuration

Sur Alpine, listez d’abord les paquets installés et la configuration effective de sshd, à exécuter en root :

apk info -v openssh-server openssh-server-pam
sshd -T | grep -iE "usepam|passwordauthentication|permitrootlogin"
cut -d: -f1,2 /etc/shadow | grep ":*$"

La première commande indique si vous utilisez le paquet sans PAM. Une ligne « usepam » absente ou à « no » signale un sshd vulnérable, d’après ComputingForGeeks et Ostorlab. La troisième liste les comptes à champ « * ». Un conteneur qui n’exécute pas sshd n’est pas exposé.

Attention : sur Alpine, « ssh -V » affiche toujours OpenSSH_10.0p2 après correction, car le correctif est rétroporté. Comparez la révision du paquet, pas la version affichée.

Corriger

Alpine a publié des paquets corrigés pour toutes les branches de la 3.16 à edge, le jour de la divulgation. Voici les versions de « openssh-server » à viser, relevées par Cycode, ComputingForGeeks et Ostorlab :

Mettez à jour puis relancez le service, car la mise à jour ne redémarre pas le sshd déjà actif :

apk upgrade -U openssh openssh-server
rc-service sshd restart

ComputingForGeeks propose « apk upgrade -U -a », mais met en garde : cette option aligne tous les paquets sur le dépôt et peut en rétrograder certains. Pour un conteneur, reconstruisez l’image depuis une base corrigée. Les images Alpine antérieures à la 3.16 n’ont pas de paquet corrigé : le seul recours est de passer aux clés seules.

Se protéger en attendant

La parade la plus simple est de désactiver les mots de passe. Avec PasswordAuthentication no, la faille ne peut plus être exploitée et les connexions se font par clé :

mkdir -p /etc/ssh/sshd_config.d
echo "PasswordAuthentication no" > /etc/ssh/sshd_config.d/00-no-passwords.conf
sshd -t
rc-service sshd restart

Le répertoire sshd_config.d n’est lu que depuis Alpine 3.19 ; sur les versions antérieures, modifiez directement sshd_config. Vérifiez aussi les blocs « Match », qui ont leur propre valeur. Passer l’option UsePAM à oui avec le paquet « openssh-server-pam » protège également.

Chercher une compromission

Cherchez dans /var/log/messages les connexions réussies par mot de passe pour des comptes qui n’en ont pas, avec grep -i "Accepted password" /var/log/messages. Contrôlez aussi les nouveaux comptes, les fichiers authorized_keys modifiés et l’usage de doas. Previdian a vu huit tentatives depuis une seule adresse, 89.116.89[.]18, qui lançaient les commandes id, uname et hostname. Si vous ne pouvez pas écarter une connexion suspecte, traitez la machine comme compromise : reconstruisez-la depuis une image de confiance et changez les identifiants accessibles.

Reste à confirmer l’inscription au catalogue de la CISA

Reste à clarifier si la faille figure au catalogue des vulnérabilités exploitées de la CISA : Help Net Security disait non le 6 novembre, Ostorlab évoque un ajout le 9 novembre. Nous mettrons cet article à jour après vérification sur le site de l’agence.