sshole (CVE-2026-123158) : vérifiez votre réseau

La CVE-2026-123158, surnommée « sshole » (aussi écrite sshhole), permet de se connecter en SSH avec un mot de passe très long sur les systèmes Linux où le sshd d'OpenSSH est compilé avec la musl libc sans PAM, Alpine Linux en étant l'exemple le plus connu. Elle est corrigée dans OpenSSH 10.6p2, publiée le 5 novembre 2026, et la désactivation de l'authentification par mot de passe la neutralise en attendant la mise à jour. La plupart des distributions serveur courantes utilisent glibc et PAM et restent en dehors de la configuration vulnérable ; le risque se concentre sur les hôtes Alpine, les conteneurs basés sur Alpine qui font tourner sshd et les images Linux embarquées.

Qui est concerné, et qui ne l'est pas

La fiche CVE la décrit ainsi : sshd dans OpenSSH avant 10.6p2, sous Linux, lorsque la musl libc est utilisée sans PAM, ne dispose pas d'un contournement pour un défaut qui permet d'outrepasser l'authentification par mot de passe ; pour certaines configurations de comptes, n'importe quel mot de passe de 256 à 1 024 caractères fonctionne. La fiche lui attribue un score de 8,1 (élevé) en CVSS 3.1.

Le mécanisme, tel que le décrivent Alpine et plusieurs chercheurs en sécurité : sans PAM, sshd vérifie un mot de passe en appelant la fonction crypt() de la bibliothèque C et en comparant le résultat à l'entrée du compte dans /etc/shadow. Pour une entrée trop longue, crypt() de musl échoue et renvoie la chaîne *. Les comptes qui ne sont pas censés se connecter par mot de passe ont souvent exactement * comme entrée shadow : la valeur d'échec correspond, et sshd accepte la connexion. Un compte doté d'une vraie empreinte de mot de passe ne s'ouvre pas ainsi : la valeur d'échec ne correspond pas à l'empreinte.

• Configuration vulnérable : OpenSSH antérieur à 10.6p2, musl libc, pas de PAM, authentification par mot de passe activée et au moins un compte dont l'entrée shadow est un simple *. La compilation OpenSSH par défaut d'Alpine n'a pas PAM. Les chercheurs citent parmi les comptes exposés les utilisateurs qui se connectent uniquement par clé et l'utilisateur par défaut des images cloud Alpine ; root a aussi * par défaut sur Alpine, mais le réglage par défaut PermitRootLogin prohibit-password refuse la connexion de root par mot de passe.
• Hors configuration, selon la fiche CVE : les distributions basées sur glibc et les compilations de sshd qui utilisent PAM. Dropbear, le serveur SSH livré par défaut avec OpenWrt, est un autre programme qu'OpenSSH et n'est pas le produit visé par la fiche ; un équipement OpenWrt n'est concerné que si le serveur OpenSSH y a été installé.
• Exploitation : un code de preuve de concept est public. La société de renseignement sur les menaces Previdian indique que ses capteurs ont observé des tentatives d'exploitation ; au 6 novembre 2026, d'autres sources, comme Safe Security, indiquaient que l'exploitation réelle n'était pas confirmée et que la CISA n'avait pas ajouté la CVE à son catalogue Known Exploited Vulnerabilities. Dans tous les cas, traitez en urgence tout hôte vulnérable qui accepte des mots de passe SSH depuis Internet.

Un contrôle de 10 minutes pour les administrateurs

N'analysez que des réseaux qui vous appartiennent ou que vous êtes autorisé à tester.

Étape 1 : repérer les services SSH

Depuis un hôte du réseau, listez tout ce qui répond sur le port 22, avec la version logicielle annoncée. Remplacez la plage d'exemple par vos propres sous-réseaux :

nmap -p 22 --open -sV 192.0.2.0/24

Incluez les hôtes de conteneurs et les réseaux de test. Un sshd dans un conteneur peut être publié sur un autre port : vérifiez aussi les redirections de ports exposées par votre plateforme de conteneurs.

Étape 2 : vérifier la version d'OpenSSH et la bibliothèque C sur chaque hôte

ssh -V affiche la version d'OpenSSH installée. ldd --version affiche musl libc sur un système musl et la version de glibc sur un système glibc. Sur Alpine, apk info -v | grep openssh donne les versions exactes des paquets.

ssh -V
ldd --version 2>&1 | head -1

Étape 3 : vérifier si la connexion par mot de passe est activée

En root, affichez la configuration avec laquelle sshd tourne réellement. passwordauthentication no signifie que cette voie est fermée sur cet hôte.

sshd -T | grep -i passwordauthentication

Étape 4 : lister les comptes avec un simple *

Ce sont les comptes que le contournement peut ouvrir :

awk -F: '$2 == "*" { print $1 }' /etc/shadow

Un hôte est exposé si les quatre conditions sont réunies : version d'OpenSSH vulnérable, musl, authentification par mot de passe activée et au moins un compte listé autorisé à se connecter en SSH.

Le correctif

1. Mettez OpenSSH à jour vers 10.6p2, ou vers le paquet corrigé de votre distribution. Sur Alpine, l'instruction publiée est apk upgrade -U -a.
2. Redémarrez sshd. Le démon en cours garde l'ancien code jusqu'au redémarrage ; sur Alpine, rc-service sshd restart.
3. En attendant la mise à jour, réglez PasswordAuthentication no dans sshd_config et rechargez sshd. Si vos utilisateurs se connectent déjà par clé, rien ne change pour eux ; c'est la mesure provisoire recommandée par les avis de sécurité.
4. Reconstruisez les images de conteneurs qui exécutent sshd sur une base Alpine, puis redéployez-les : corriger l'hôte ne corrige pas l'image.
5. Passez en revue les connexions SSH récentes sur les hôtes concernés, en particulier les connexions par mot de passe réussies sur des comptes qui utilisent normalement des clés ou ne se connectent jamais.

Ce que la surveillance réseau voit, et ce qu'elle ne voit pas

SSH est chiffré : le mot de passe ne traverse jamais le réseau en clair. Un capteur réseau ne voit ni le mot de passe ni sa longueur, et ne peut pas dire que cette faille précise a été utilisée : cette preuve se trouve dans les journaux de l'hôte.

Ce que la surveillance réseau voit, c'est le comportement autour d'une compromission. NetSenX évalue le comportement de chaque hôte sur le réseau et signale les scans, les mouvements latéraux, le beaconing C2 et les volumes inhabituels de données sortantes, sur toutes les offres, y compris Free. Un hôte qui accepte soudain des sessions SSH depuis des sources avec lesquelles il n'a jamais communiqué, ou un conteneur Alpine qui se met à contacter d'autres hôtes internes après une connexion, est exactement le type de changement auquel servent ces détections. Chaque alerte explique en langage clair pourquoi elle s'est déclenchée. Utilisez-la en complément des contrôles sur les hôtes ci-dessus, pas à leur place.

Si vous n'êtes pas sûr que personne ne se trouve déjà dans le réseau, Comment savoir si quelqu'un est dans votre réseau présente les signes et les contrôles gratuits, Détecter les mouvements latéraux et le beaconing C2 relie à MITRE ATT&CK ce qui suit une connexion, et NDR, EDR ou SIEM explique quel outil voit quoi. L'offre Free surveille jusqu'à 3 appareils sans limite de durée ; voir les tarifs.

FAQ

Sources

Toutes consultées le 6 novembre 2026.

• CVE-2026-123158, fiche CVE (cvelistV5) — description, versions concernées, score CVSS 3.1 de 8,1, publiée le 5 novembre 2026
• Alpine Linux — OpenSSH password authentication bypass — l'avis de la distribution
• OpenSSH release notes, 10.6p2
• OX Security — OpenSSH password authentication bypass on Alpine Linux — mécanisme et comptes exposés
• Previdian — CVE-2026-123158 exploitation attempts observed
• Safe Security — SSHole: high-severity OpenSSH vulnerability — état de l'exploitation au 6 novembre 2026

Rédigé par l'équipe NetSenX chez TriStiX S.L. Cet article est une information générale fondée sur les sources publiques ci-dessus au 6 novembre 2026 ; vérifiez dans l'avis de votre distribution les versions de paquets qui vous concernent. Questions : info@netsenx.com.