OpenSSH musl : la faille CVE-2026-123158 corrigée

OpenSSH musl est le nom donné à une faille d’authentification que le CERT-FR a signalée le 5 novembre 2026 dans son alerte CERTFR-2026-ALE-015. Elle touche les serveurs OpenSSH compilés avec la bibliothèque musl et sans module PAM, une configuration courante sur Alpine Linux, OpenWrt, Buildroot ou Yocto. Référencée CVE-2026-123158, elle permet à un attaquant de contourner l’authentification par mot de passe sur un compte précis. Un correctif existe depuis le 5 novembre (OpenSSH 10.6p2) : voici qui est concerné et comment vérifier vos serveurs.

OpenSSH musl : qui est concerné ? #

La faille ne touche pas OpenSSH « en général » : elle suppose une combinaison précise de conditions.

Les distributions construites sur musl sont les premières concernées, Alpine Linux en tête puisqu’elle l’utilise par défaut pour son paquet openssh-server. OpenWrt (qui utilise le plus souvent Dropbear plutôt qu’OpenSSH), Buildroot et Yocto doivent être vérifiés au cas par cas selon leur configuration réelle. Les distributions basées sur glibc, comme Debian, Ubuntu ou Fedora, ne sont pas concernées par cette faille précise.

Comment fonctionne le contournement d’authentification ? #

Sans détailler de code d’exploitation, le principe repris par les bulletins publiés est le suivant : sur musl, la fonction crypt() renvoie la valeur * lorsqu’un mot de passe soumis dépasse une certaine longueur, plutôt que de renvoyer une erreur. Un mécanisme de comparaison plus ancien dans OpenSSH peut alors confondre cette valeur de retour avec le marqueur * utilisé dans /etc/shadow pour désigner un compte sans mot de passe utilisable. En soumettant un mot de passe suffisamment long pour un compte visé, un attaquant peut obtenir une authentification acceptée sans connaître de mot de passe valide. La condition de longueur précise (supérieure à 256 caractères selon les bulletins) limite le risque d’un déclenchement accidentel, mais n’empêche pas une exploitation volontaire une fois les conditions réunies. Les éditeurs n’évoquent pour l’instant aucune campagne d’exploitation active confirmée : il s’agit d’un risque à corriger avant qu’il ne soit exploité, pas d’une attaque en cours documentée.

Côté sévérité, selon le site spécialisé cyberattaque.org, la faille reçoit un score CVSS v3.1 de 8,1, cohérent avec un contournement d’authentification conditionné à une configuration particulière plutôt qu’ouvert par défaut.

Que faire ? Corriger et vérifier vos serveurs #

• Mettre à jour OpenSSH vers la version 10.6p2 ou supérieure, ou installer le correctif rétroporté par votre distribution : Alpine a rétroporté le correctif sur ses branches maintenues, vérifiez donc la version du paquet plutôt que le seul numéro de version d’OpenSSH affiché.
• Redémarrer le service sshd après toute mise à jour ou modification de configuration : un correctif installé sans redémarrage laisse le serveur vulnérable.
• En attendant le correctif, désactivez l’authentification par mot de passe au profit de clés SSH, ou coupez temporairement le service si le serveur n’a pas besoin d’être accessible.
• Inventoriez les systèmes musl exposés : images Alpine en production, équipements embarqués (OpenWrt, Buildroot, Yocto), conteneurs construits sur une image Alpine avec SSH activé. Notre base de données CVE vous permet de suivre cette référence et les futures mises à jour associées.
• Vérifiez les journaux d’authentification à la recherche d’entrées « Accepted password » concernant des comptes dont le champ mot de passe de /etc/shadow est *, signe possible d’une tentative ou d’une exploitation.
• Pour administrer un serveur ponctuellement sans ouvrir davantage votre pare-feu, notre client SSH web évite d’exposer un port SSH supplémentaire depuis votre poste.

L’angle France : l’alerte du CERT-FR #

Le CERT-FR, le centre gouvernemental de veille, d’alerte et de réponse aux attaques informatiques de l’ANSSI, a publié son alerte dès le 5 novembre 2026, avant même l’attribution publique du numéro CVE, puis l’a complétée le 6 novembre pour y ajouter la référence CVE-2026-123158. Ce délai court entre le signalement du chercheur à l’origine de la découverte, le 3 novembre, le correctif et la divulgation le 5, puis l’alerte officielle, illustre la place que prend désormais la chaîne logicielle embarquée (objets connectés, équipements réseau, conteneurs) dans la surveillance de l’ANSSI, au même titre que les serveurs applicatifs classiques. Cette faille s’ajoute à une série de vulnérabilités Linux récentes, comme les trois failles du noyau Linux inscrites au catalogue CISA KEV ou la faille CVE-2026-98432 toujours sans correctif.

L’avis de ForenShield #

Cette faille est un bon test de votre inventaire logiciel plus qu’une urgence généralisée : la priorité du jour est de savoir si vous exploitez réellement du musl en production, pas de traiter chaque serveur Linux de la même façon. Commencez par les équipements qui exposent SSH à un réseau non maîtrisé (bastions, équipements réseau administrables à distance, conteneurs Alpine exposés par erreur) : ce sont ceux-là qui doivent être corrigés aujourd’hui. Les postes glibc classiques (Debian, Ubuntu, Red Hat) peuvent suivre un cycle de correctifs normal, puisqu’ils ne sont pas concernés par cette faille précise.

Le piège le plus fréquent sur ce type de correctif consiste à mettre à jour le paquet sans redémarrer sshd, ce qui laisse le service tourner avec le code vulnérable en mémoire : vérifiez systématiquement la version effective chargée par le processus, pas seulement celle installée sur le disque. Deuxième piège : confondre la version d’OpenSSH annoncée par le fournisseur de l’image avec celle réellement corrigée, certaines distributions rétroportant le correctif sans changer le numéro de version affiché.

Après correction, vérifiez qu’aucun compte à champ * n’a servi récemment à une connexion acceptée dans vos journaux, et que l’authentification par mot de passe reste désactivée là où elle n’est pas strictement nécessaire : c’est la meilleure protection contre la prochaine variante de ce type de faille.

Points clés #

• Une faille d’authentification (CVE-2026-123158) touche OpenSSH sur les systèmes Linux basés sur musl et sans PAM : Alpine Linux, OpenWrt, Buildroot, Yocto notamment.
• Elle exploite une particularité de la fonction crypt() de musl avec un mot de passe anormalement long, pour contourner l’authentification d’un compte dont le mot de passe vaut * dans /etc/shadow.
• Le correctif est disponible dans OpenSSH 10.6p2 et dans les paquets rétroportés par les distributions concernées ; aucune exploitation active n’est confirmée à ce stade.
• Les systèmes glibc (Debian, Ubuntu, Fedora) ne sont pas concernés par cette faille précise.
• Priorité : inventoriez vos systèmes musl exposés, corrigez et redémarrez sshd, puis vérifiez vos journaux d’authentification.