Réponse courte : la faille OpenSSH CVE-2026-123158, surnommée « sshhole », permet de se connecter en SSH sans connaître le mot de passe sur certains systèmes Linux utilisant la bibliothèque musl sans PAM, typiquement Alpine Linux. Les serveurs Debian, Ubuntu ou Red Hat ne sont pas concernés. La correction : passer à OpenSSH 10.6p2 ou au paquet corrigé, puis redémarrer sshd.
Le 5 novembre 2026, le projet OpenSSH a publié la version 10.6p2 pour corriger une faille OpenSSH de contournement d’authentification. Le jour même, le CERT-FR (ANSSI) a émis l’alerte CERTFR-2026-ALE-015, mise à jour le 6 novembre avec l’identifiant CVE-2026-123158. Une alerte, chez le CERT-FR, est réservée aux menaces jugées sérieuses. Voici ce qu’une PME doit vérifier, sans paniquer, mais sans attendre.
Qu’est-ce que la faille OpenSSH CVE-2026-123158 ?
C’est un contournement de l’authentification par mot de passe dans sshd, le service qui accepte les connexions SSH à distance.
Elle a été découverte par Özgün Kültekin, de la société Wakefield, qui l’a baptisée « sshhole ». Son score CVSS 3.1 est de 8,1 sur 10, soit un niveau « élevé ». Selon les analyses publiées par TuxCare et Cyber Kendra, le chemin de code en cause remonte à OpenSSH 7.3, sorti en 2016. La faille a donc dormi près de dix ans.
Point notable : les développeurs d’OpenSSH estiment que la cause racine se situe hors de sshd, dans la manière dont la vérification du mot de passe interagit avec la bibliothèque C musl. Mais c’est bien via sshd qu’elle s’exploite, d’où la correction côté OpenSSH.
Quels systèmes sont réellement concernés ?
Seuls les systèmes Linux qui utilisent la bibliothèque musl et dont sshd fonctionne sans PAM sont exposés.
En pratique, la cible principale est Alpine Linux, dont le paquet openssh-server par défaut est compilé sans PAM. Alpine est très répandu dans les conteneurs Docker, les petites machines virtuelles cloud et certains équipements embarqués.
| Système | Concerné ? |
|---|---|
| Alpine Linux avec sshd et mots de passe activés | Oui, si non mis à jour |
| Conteneur Docker basé sur Alpine sans sshd | Non |
| Conteneur Alpine dans lequel on a ajouté sshd | Oui |
| Debian, Ubuntu, Red Hat, Rocky (glibc) | Non |
| Serveur où l’authentification par mot de passe est désactivée | Non |
| Windows, macOS | Non |
Les conditions d’exploitation détaillées par le CERT-FR sont précises : l’attaquant fournit un mot de passe de plus de 256 caractères, et le compte visé est un compte sans mot de passe défini, marqué par un astérisque « * » dans le fichier /etc/shadow. Ce sont souvent des comptes prévus pour une connexion par clé uniquement. Les comptes verrouillés avec « ! » ne sont pas touchés.
La faille est-elle déjà exploitée par des pirates ?
À ce jour, aucune exploitation active n’a été signalée, mais une preuve de concept est publique.
Ni OpenSSH ni Alpine ne rapportent d’attaques, et la faille ne figure pas dans le catalogue des vulnérabilités exploitées de la CISA. En revanche, le CERT-FR qualifie l’exploitation de « triviale » lorsque les conditions sont réunies. Avec un code de démonstration en circulation, le délai avant les premiers scans automatisés se compte souvent en jours. Un serveur SSH exposé sur Internet est scanné en permanence.
Comment vérifier et corriger mes serveurs ?
Inventoriez vos machines Alpine qui font tourner sshd, mettez à jour OpenSSH, puis redémarrez le service.
- Inventaire : listez les machines virtuelles, serveurs cloud, conteneurs et équipements qui exposent SSH. Repérez ceux qui tournent sous Alpine (fichier /etc/alpine-release).
- Mise à jour : installez OpenSSH 10.6p2 ou le paquet corrigé publié par Alpine pour votre branche (apk update puis apk upgrade openssh). Alpine a aussi livré des correctifs pour des branches anciennes.
- Redémarrage de sshd : le CERT-FR insiste sur ce point. Sans redémarrage, l’ancien code reste actif.
- Conteneurs : reconstruisez les images qui embarquent sshd sur une base corrigée, puis redéployez-les.
- Mesure provisoire si vous ne pouvez pas mettre à jour : passez PasswordAuthentication à no dans /etc/ssh/sshd_config, ou coupez le service. Sur les anciennes versions d’Alpine, éditez le fichier principal, les fichiers du dossier sshd_config.d n’étant pas pris en compte.
- Recherche de compromission : repérez les comptes marqués « * » dans /etc/shadow et cherchez dans les journaux des lignes « Accepted password for » associées à ces comptes.
- En cas de doute : si un accès illégitime ne peut pas être exclu, traitez la machine comme compromise (réinstallation, rotation des secrets).
Ce type d’opération relève de la gestion des correctifs : un inventaire à jour transforme une alerte stressante en tâche de routine.
Pourquoi cette faille concerne aussi les PME ?
Parce que beaucoup de PME utilisent Alpine sans le savoir, via un prestataire, une application en conteneur ou un serveur cloud bon marché.
Un site web hébergé sur un petit serveur virtuel, un outil métier livré en Docker, une passerelle installée par un intégrateur : autant de machines qui peuvent embarquer un sshd vulnérable. Les images cloud officielles d’Alpine créent par ailleurs un compte « alpine » sans mot de passe défini, exactement le profil visé, dès qu’un autre compte de la machine possède un mot de passe. Certains systèmes embarqués compilés avec musl (routeurs, objets connectés) peuvent aussi être concernés, sans correctif publié à ce stade pour toutes les distributions embarquées.
Le vrai risque n’est pas la faille en elle-même. C’est de ne pas savoir quelles machines existent. C’est le même constat que lors des failles Ivanti Connect Secure d’octobre.
L’avis de l’expert
Dans les grands comptes où j’ai piloté le patch management, comme la RATP, la Société Générale ou LVMH, une alerte CERT-FR déclenche un processus clair : qualification en quelques heures, liste des actifs touchés, correctif ou mesure de contournement, puis vérification. Ce qui fait la différence, ce n’est pas la taille de l’équipe, c’est l’inventaire.
Sur sshhole, la bonne nouvelle est que le périmètre est étroit. La mauvaise, c’est qu’il se cache dans des coins qu’on ne regarde jamais : un conteneur oublié, une VM de test restée en ligne. Mon conseil aux PME : désactivez l’authentification SSH par mot de passe partout où c’est possible, au profit des clés. Cette seule règle neutralise la faille, même sans patch. Et n’exposez jamais SSH directement sur Internet sans filtrage par adresse IP ou VPN.
Enfin, retenez le détail du redémarrage. Combien de fois ai-je vu un paquet « corrigé » sur le papier alors que le service tournait encore avec l’ancien binaire ? Une mise à jour n’est terminée que lorsqu’elle est vérifiée. C’est le sens des mises à jour de sécurité bien faites.
Et pour les PME et les particuliers du 92 ?
Les particuliers sont très rarement concernés : un PC sous Windows ou un Mac n’est pas touché.
Si vous avez installé vous-même un mini-serveur ou un conteneur Docker à la maison, vérifiez-le avec la méthode ci-dessus. Pour les PME de La Garenne-Colombes, Nanterre, Courbevoie, Colombes ou Puteaux, SOSPC82 peut réaliser un inventaire rapide des machines exposant SSH et appliquer les correctifs, à distance ou sur site. Un audit cybersécurité PME permet aussi de repérer les services exposés inutilement. En cas de suspicion d’intrusion, notre équipe de réponse à incident cyber intervient 24 h/24 et 7 j/7.
Questions fréquentes
Mon serveur Ubuntu est-il vulnérable à sshhole ?
Non. Ubuntu, Debian et Red Hat utilisent la bibliothèque glibc, qui n’est pas concernée. Gardez tout de même OpenSSH à jour, comme pour toute faille.
Quelle version d’OpenSSH corrige la faille ?
OpenSSH 10.6p2, publiée le 5 novembre 2026. Sur Alpine, installez le paquet corrigé de votre branche, puis redémarrez sshd.
Désactiver les mots de passe SSH suffit-il ?
Oui, c’est la mesure de contournement recommandée par le CERT-FR si vous ne pouvez pas mettre à jour immédiatement. La connexion par clé n’est pas affectée par cette faille.
Mon image Docker Alpine est-elle à risque ?
Seulement si sshd est installé et lancé dans le conteneur avec des comptes à mot de passe. L’image de base seule n’expose pas SSH.
Comment savoir si j’ai été piraté ?
Cherchez dans les journaux des connexions par mot de passe réussies sur des comptes marqués « * » dans /etc/shadow. Si un doute persiste, considérez la machine comme compromise et faites appel à un spécialiste.
En résumé
- La faille OpenSSH CVE-2026-123158 (sshhole) permet une connexion SSH sans mot de passe sur les Linux musl sans PAM, surtout Alpine.
- Correctif : OpenSSH 10.6p2 ou paquet Alpine corrigé, suivi d’un redémarrage de sshd ; à défaut, désactiver l’authentification par mot de passe.
- Aucune attaque signalée à ce jour, mais une preuve de concept est publique : agissez dans la semaine.
Vous ne savez pas quelles machines de votre entreprise exposent SSH ? Découvrez notre offre d’infogérance PME, avec patch management inclus, à partir de 19,99 € HT par poste et par mois, ou appelez le 07 69 36 92 60 pour un devis gratuit sous 24 h.
Article rédigé par Kevin Aquino, Technical Lead patch management et fondateur de SOSPC82
Sources :