Linux : la faille SSH CVE-2026-123158 contourne le mot de passe sur certaines configurations

Une faille d’authentification SSH vient de rappeler qu’un détail de bibliothèque système peut suffire à fragiliser un serveur Linux. Référencée sous le nom CVE-2026-123158, elle permet, dans une configuration bien précise, de contourner la vérification du mot de passe avec une chaîne anormalement longue, comprise entre 257 et 1 024 octets. Le problème touche notamment des installations Alpine Linux utilisant OpenSSH sans PAM : il ne s’agit donc pas d’une faille qui rendrait toutes les distributions Linux vulnérables.

La bonne nouvelle, c’est qu’un correctif est déjà disponible. Le projet OpenSSH a publié la version 10.6p2 le 5 novembre 2026, tandis qu’Alpine a diffusé des paquets corrigés pour ses branches stables. Les administrateurs doivent toutefois vérifier leur configuration et redémarrer le service SSH après la mise à jour : remplacer le paquet ne suffit pas à relancer le démon déjà en mémoire.

CVE-2026-123158 : quelles conditions rendent un serveur vulnérable ?

Le scénario décrit par les mainteneurs d’Alpine exige plusieurs conditions cumulatives. La machine doit utiliser OpenSSH construit avec la bibliothèque C musl et sans intégration PAM, ou être configurée de manière équivalente avec UsePAM no. L’authentification SSH par mot de passe doit rester activée. Enfin, certains comptes doivent présenter un champ de mot de passe égal à * dans la base des comptes, tandis qu’au moins un autre compte local possède un hash de mot de passe au format $5$ ou $6$.

Ces conditions expliquent pourquoi Alpine Linux est particulièrement concerné : son paquet openssh-server standard est construit sans PAM. Les images minimales et les environnements embarqués méritent aussi un contrôle attentif lorsqu’ils combinent musl, OpenSSH sans PAM et les réglages de comptes décrits dans l’avis. En revanche, la simple présence de Linux ou d’OpenSSH ne suffit pas à conclure qu’un système est exposé.

L’avis officiel d’Alpine précise également les cas qui échappent au scénario : un serveur avec PasswordAuthentication no, un paquet openssh-server-pam utilisé avec UsePAM yes, ou un environnement où les conditions de comptes nécessaires ne sont pas réunies. Les conteneurs qui n’exécutent pas de serveur sshd ne sont pas concernés par cette voie d’attaque.

Pourquoi un mot de passe de 257 à 1 024 caractères peut-il passer ?

Le défaut se situe dans la manière dont le serveur vérifie le mot de passe lorsqu’il fonctionne sans PAM. OpenSSH s’appuie alors sur la fonction crypt() de la bibliothèque C pour calculer une valeur à comparer au champ enregistré pour le compte. Si le champ est trop court pour contenir un sel de hachage exploitable, le code peut réutiliser le sel d’un autre compte.

Avec musl, une tentative de hachage portant sur une entrée dépassant 256 octets provoque le retour de la chaîne *, utilisée comme indicateur d’erreur. Or ce même caractère peut se trouver dans le champ de mot de passe d’un compte sans mot de passe défini. Dans les circonstances précises décrites par Alpine, la comparaison aboutit alors à une correspondance inattendue : le serveur accepte la tentative au lieu de la rejeter.

Il ne s’agit donc pas d’un mot de passe universel qui fonctionnerait sur n’importe quel serveur. La longueur de l’entrée déclenche un comportement particulier de musl, mais l’exploitation dépend aussi du mode de compilation d’OpenSSH, des options d’authentification et de l’état des comptes. La faille a été signalée par Özgün Kültekin, crédité dans les notes de version officielles d’OpenSSH.

Alpine Linux publie des paquets corrigés pour plusieurs branches

Alpine a accompagné son avis de sécurité de mises à jour pour les branches maintenues. Les versions stables 3.21.10, 3.22.8, 3.23.8 et 3.24.4 incluent le correctif. Les versions de paquet OpenSSH corrigées diffèrent selon la branche : il faut donc suivre l’avis correspondant à sa version d’Alpine plutôt que chercher uniquement le numéro 10.6p2.

Les administrateurs d’images cloud ou de systèmes construits sur mesure ne doivent pas se fier au seul nom de la distribution. Il faut contrôler le paquet réellement installé, la présence de PAM, la valeur effective de PasswordAuthentication et les comptes locaux. Pour Buildroot, Yocto ou certaines configurations OpenWrt, la présence de musl ne constitue pas à elle seule une preuve d’exposition : la configuration et la construction d’OpenSSH doivent être examinées.

Comment protéger immédiatement son serveur SSH ?

La priorité est d’installer le paquet corrigé fourni par sa distribution, puis de redémarrer le service SSH. Sur Alpine, la commande de mise à niveau générale recommandée dans l’avis est apk upgrade -U -a, suivie de rc-service sshd restart. Les administrateurs doivent adapter la procédure à leur branche et à leurs pratiques de maintenance.

Si la mise à jour ne peut pas être appliquée immédiatement, Alpine recommande de désactiver l’authentification par mot de passe avec PasswordAuthentication no, puis de redémarrer sshd. Avant toute modification à distance, vérifiez dans une seconde session que l’authentification par clé fonctionne et conservez la session actuelle ouverte : une erreur de configuration pourrait autrement vous couper l’accès au serveur.

Après le correctif, il est également prudent d’examiner les journaux SSH à la recherche de connexions par mot de passe acceptées pour des comptes censés ne pas en posséder, notamment les comptes de service ou les comptes prévus pour une connexion par clé uniquement. Si une connexion anormale ne peut pas être écartée, il faut traiter la machine comme potentiellement compromise : examiner les comptes, les clés autorisées, les usages de privilèges et les fichiers récemment modifiés.

Pour les joueurs qui utilisent Steam Deck ou un PC sous Linux, cette actualité s’inscrit dans un environnement où les mises à jour de sécurité comptent autant que les évolutions de compatibilité. Nous avions déjà détaillé les failles du noyau Linux signalées en octobre et les précautions autour de SteamOS. Les utilisateurs de Linux peuvent aussi retrouver nos actualités sur les évolutions récentes de l’écosystème Linux.

Ce qu’il faut retenir

CVE-2026-123158 est une faille sérieuse, mais son périmètre est conditionnel : elle vise des configurations OpenSSH utilisant musl sans PAM, avec l’authentification par mot de passe active et des états de comptes spécifiques. OpenSSH 10.6p2 contient le correctif en amont, et Alpine fournit également des paquets corrigés pour ses branches stables. La démarche la plus sûre reste de mettre à jour le paquet adapté à sa distribution, de redémarrer le démon SSH et, dans l’intervalle, de désactiver l’authentification par mot de passe après avoir vérifié l’accès par clé.

Sources officielles : notes de version OpenSSH 10.6p2 ; avis de sécurité Alpine Linux ; annonce des versions stables Alpine corrigées ; fiche CVE-2026-123158 de Red Hat.