OpenSSH 10.6p2 corrige un contournement d'authentification sur musl

OpenSSH 10.6p2, publié le 5 novembre 2026, corrige une faille d'authentification sur les systèmes Linux bâtis avec la bibliothèque musl. Le CERT-FR a émis une alerte, CERTFR-2026-ALE-015, et juge l'exploitation « triviale » lorsque les conditions sont réunies. Aucun CVE n'était attribué à la publication. Le correctif figure dans les notes de version d'OpenSSH.

Systèmes concernés

• OpenSSH antérieur à 10.6p2, compilé avec musl, sans PAM ou avec PAM désactivé, et authentification par mot de passe activée.
• Distributions et systèmes de build en musl : Alpine Linux, OpenWrt, Buildroot, Yocto.
• Les systèmes en glibc (Debian, Ubuntu, Fedora) et ceux qui authentifient via PAM ne sont pas concernés.

Le mécanisme

Un compte dont la connexion par mot de passe est désactivée porte * dans son champ de hachage. Sur musl, crypt() renvoie * quand le hachage échoue. D'après le CERT-FR, la connexion devient possible avec un second mot de passe de plus de 256 et moins de 1024 caractères : le * renvoyé correspond alors au * stocké et la comparaison réussit. Les comptes disposant d'un hachage valide ne sont pas contournables.

Le risque est accru sur les images cloud : les images AWS et Azure d'Alpine embarquent un compte alpine par défaut avec doas sans mot de passe, ouvrant une voie vers root.

Statut d'exploitation

Aucune exploitation en conditions réelles n'est signalée. Le CERT-FR qualifie l'exploitation de triviale une fois les prérequis réunis.

Que faire

1. Appliquer le correctif OpenSSH 10.6p2. Sur Alpine : apk upgrade openssh, puis redémarrer sshd.
2. À défaut, désactiver l'authentification par mot de passe (PasswordAuthentication no dans sshd_config) et redémarrer le service — cela ferme le vecteur. Si rien n'est possible, désactiver le service SSH.
3. Vérifier la légitimité des connexions des comptes dont le mot de passe est désactivé dans /etc/shadow, en les croisant avec les journaux :

grep '^alpine:' /etc/shadow
grep "Accepted password" /var/log/messages

4. Sur les images cloud Alpine, contrôler la configuration doas du compte alpine et retirer l'escalade sans mot de passe là où elle n'est pas nécessaire.

Contexte

OpenSSH se déploie souvent à l'identique sur des parcs hétérogènes. Ici, la faille ne tient pas à sshd lui-même mais au comportement de la libc : une divergence de musl que la couche portable d'OpenSSH ne normalise pas. Les opérateurs qui poussent la même configuration sshd sur du glibc et du musl ne doivent pas supposer que les propriétés de sécurité se transposent. Le CERT-FR ayant émis une alerte — niveau supérieur à un simple avis — le correctif 10.6p2 est à déployer sans attendre sur les flottes concernées.