Une faille d’OpenSSH permet, dans certaines configurations, de se connecter à un serveur Linux sans connaître le mot de passe, en une seule tentative. Le CERT-FR a émis le 5 novembre une alerte (CERTFR-2026-ALE-015), mise à jour le 6 novembre avec l’identifiant CVE-2026-123158. Les systèmes Alpine Linux, distribution bâtie sur musl, sont les premiers concernés ; le correctif impose de redémarrer le service SSH.
Une connexion sans mot de passe, sous conditions
La vulnérabilité touche les versions d’OpenSSH antérieures à 10.6p2, mais seulement sur des systèmes Linux qui utilisent la bibliothèque C musl et dont le démon SSH fonctionne sans PAM, le module d’authentification habituel. Selon le CERT-FR, un attaquant peut alors ouvrir une session en envoyant deux mots de passe successifs, le second comptant plus de 256 et moins de 1 024 caractères. L’agence gouvernementale juge l’exploitation « triviale » lorsque ces conditions sont réunies. Son alerte ne fait pas état d’attaques constatées.
Le bulletin d’Alpine Linux, publié le même jour, précise la liste complète des conditions. Il faut que le paquet openssh-server soit compilé sans PAM (ou que la variante avec PAM soit réglée sur UsePAM no), que l’authentification par mot de passe soit active, ce qui est le réglage par défaut d’OpenSSH, qu’au moins un compte ait pour mot de passe le marqueur « * » et qu’au moins un compte local possède un mot de passe haché au format $5$ ou $6$.
L’origine : un code d’erreur confondu avec un mot de passe
Le mécanisme, détaillé par Alpine, tient à une coïncidence malheureuse. Sans PAM, sshd vérifie un mot de passe en le hachant avec la fonction crypt() puis en comparant le résultat à la valeur enregistrée. Pour les comptes dont la valeur stockée est trop courte pour contenir un sel, le programme emprunte celui d’un autre compte. Or, dans musl, crypt() renvoie « * » pour signaler une erreur lorsque la clé dépasse 256 octets. Comme « * » est justement la valeur inscrite pour les comptes sans mot de passe, la comparaison réussit et la porte s’ouvre.
Les mainteneurs d’OpenSSH estiment, dans les notes de version de la 10.6p2 publiées le 5 novembre, que la cause profonde se situe hors de sshd ; ils ont néanmoins intégré un contournement qui ferme ce chemin d’exploitation. La faille a été signalée par Özgün Kültekin, de la société Wakefield, et corrigée par Damien Miller et Darren Tucker.
Qui est exposé
Alpine indique que toutes ses versions vérifiées sont touchées, de la 3.21 à la 3.24 ainsi que la branche edge, mais aussi des versions plus anciennes, de la 3.16 à la 3.20. Des paquets corrigés ont été publiés jusqu’à la 3.16, y compris pour la 3.21 dont le support a pris fin le 1er novembre. Le compte root, livré avec un mot de passe « * » depuis environ la version 3.16, n’est atteignable que si PermitRootLogin yes est activé, mais un autre compte capable de devenir administrateur suffit.
Un cas mérite une attention particulière : les images cloud « tiny-cloud » d’Alpine, de la 3.18.11 à la 3.24.3, incluent un utilisateur alpine sans mot de passe et autorisé à utiliser doas sans saisie. Saines au premier démarrage, elles deviennent vulnérables dès qu’un hachage $6$ apparaît sur la machine, par exemple quand un administrateur définit un mot de passe de console.
Ne sont pas concernés, selon Alpine : les conteneurs qui ne font pas tourner sshd, les systèmes où l’authentification par mot de passe est désactivée, la variante avec PAM activé, les comptes verrouillés par « ! » et les images cloud-init configurées sans mot de passe.
Ce que les administrateurs doivent faire
- Mettre à jour puis redémarrer sshd. Le CERT-FR insiste : installer le paquet ne remplace pas le démon déjà en mémoire. Sur Alpine, les versions corrigées sont notamment 10.3_p1-r2 pour la 3.24 et 10.2_p1-r1 pour la 3.23, et les éditions ponctuelles 3.21.10, 3.22.8, 3.23.8 et 3.24.4 intègrent le correctif.
- À défaut, couper l’authentification par mot de passe après avoir vérifié que la connexion par clé fonctionne, en gardant une session ouverte. Si même cela est impossible, le CERT-FR recommande de désactiver le service SSH.
- Chercher des traces d’intrusion. Il s’agit de repérer dans les journaux des connexions acceptées par mot de passe sur des comptes qui n’en ont pas, puis de contrôler l’usage de doas, les comptes récemment créés et les clés autorisées. Alpine conseille de considérer la machine comme compromise si une connexion suspecte ne peut pas être exclue.
Pour une entreprise, la difficulté est surtout l’inventaire : des serveurs Alpine se cachent souvent dans des machines virtuelles oubliées, des appliances ou des images cloud déployées en série. C’est cet angle mort qu’il faut traiter en premier.
Questions fréquentes
Mon serveur Debian ou Ubuntu est-il concerné par CVE-2026-123158 ?
Les conditions décrites par le CERT-FR visent les systèmes Linux reposant sur la bibliothèque musl avec PAM désactivé. Un serveur qui ne réunit pas ces conditions n’entre pas dans le périmètre de l’alerte, mais la mise à jour d’OpenSSH reste recommandée.
Les conteneurs Docker basés sur Alpine sont-ils vulnérables ?
Seulement s’ils exécutent un serveur SSH. Selon Alpine, un conteneur qui ne lance pas sshd n’est pas exposé.
Faut-il redémarrer après la mise à jour ?
Oui. Le CERT-FR et Alpine rappellent que la mise à jour du paquet ne suffit pas : il faut relancer le service sshd pour que la version corrigée soit réellement en fonctionnement.
Sources
- [MàJ] Vulnérabilité dans OpenSSH (CERTFR-2026-ALE-015) — CERT-FR, 2026-11-06
- Security advisory: openssh-server password authentication bypass — Alpine Linux, 2026-11-05
- OpenSSH 10.6p2 (release-10.6p2) — OpenSSH, 2026-11-05