OpenSSH : l’authentification par mot de passe contournable sur les systèmes Linux musl sans PAM, alerte le CERT-FR

Veille cyber Top-Secured : analyse indépendante fondée sur les sources citées plus bas. Top-Secured n'est pas affilié aux entreprises mentionnées et ne vous demandera jamais vos identifiants bancaires ni vos mots de passe.

OpenSSH a publié le 5 novembre 2026 la version 10.6p2 pour corriger un contournement de l’authentification par mot de passe dans sshd, qui touche les systèmes Linux reposant sur la bibliothèque C musl et sans PAM, comme beaucoup de serveurs et conteneurs Alpine. Le CERT-FR a émis une alerte le jour même et juge l’exploitation triviale lorsque les conditions sont réunies.

Ce qui s’est passé

Le projet OpenSSH a publié le 5 novembre 2026 la version portable OpenSSH 10.6p2, qui corrige un contournement de l’authentification par mot de passe exploitable via sshd. D’après les notes de version, le problème de fond ne se situe pas dans OpenSSH, mais sshd a été modifié pour l’éviter. Le CERT-FR a publié dans la foulée l’alerte CERTFR-2026-ALE-015 : toutes les versions antérieures à 10.6p2 sont concernées et l’exploitation est qualifiée de triviale si les conditions sont remplies. Aucun identifiant CVE n’est indiqué, et aucune des deux sources ne fait état d’attaques à ce jour.

Qui est concerné

Seuls les systèmes Linux qui utilisent la bibliothèque C musl et font tourner sshd sans PAM sont visés. Selon le chercheur à l’origine de la découverte, la fonction crypt() de musl échoue au-delà de 256 octets et renvoie alors *, justement la valeur qui signale un compte sans mot de passe utilisable dans /etc/shadow. Un attaquant peut ainsi entrer sur un tel compte (utilisateurs à clé uniquement, ou root sur les Alpine récentes, d’après le chercheur) avec un mot de passe démesuré, si l’authentification par mot de passe est active. Le chercheur cite Alpine, OpenWrt, Buildroot, Yocto et les images Docker qui en dérivent. Les distributions basées sur glibc, les configurations avec PAM et Dropbear ne sont pas touchés, selon la même analyse.

Que faire maintenant

1. Repérez les systèmes exposés : ldd --version affiche musl sur les plateformes concernées ; contrôlez sshd -T | grep -Ei 'usepam|passwordauthentication'.
2. Mettez à jour : apk upgrade openssh, puis vérifiez que ssh -V indique 10.6p2. Reconstruisez et redéployez les images de conteneurs qui embarquent sshd.
3. Si la mise à jour doit attendre, coupez les connexions par mot de passe avec PasswordAuthentication no dans un fichier de /etc/ssh/sshd_config.d/, puis redémarrez sshd (rc-service sshd restart). À défaut, le CERT-FR recommande d’arrêter le service SSH.
4. Cherchez des traces : listez les comptes dont le mot de passe vaut * (grep -E '^[^:]+:\*:' /etc/shadow | cut -d: -f1) et recherchez des lignes Accepted password for les concernant dans /var/log/messages, comme le suggère le CERT-FR.

Notre avis

Les images légères sont partout, dans les conteneurs comme dans les équipements, et elles héritent des réglages par défaut de leur système de base, SSH sans PAM compris. L’authentification par clé seule doit être imposée noir sur blanc dans la configuration, pas supposée : avec PasswordAuthentication no, cette faille aurait été sans effet.

Sources

• CERT-FR — CERTFR-2026-ALE-015 : Vulnérabilité dans OpenSSH
• OpenSSH — Release notes for OpenSSH 10.6p2
• sshhole — OpenSSH password bypass on musl libc (researcher write-up)

Comment nous choisissons, vérifions et rédigeons nos analyses →