SSHole (aussi écrit *sshole ou SSHhole) est le surnom de la CVE-2026-123158 : un contournement de l’authentification par mot de passe dans OpenSSH qui touche Alpine Linux et les systèmes basés sur la musl libc. Notée 8.1 en CVSS 3.1, corrigée dans OpenSSH 10.6p2, elle est exploitée activement depuis le 6 novembre 2026. Voici pourquoi le délai entre sa divulgation et son exploitation impose de patcher immédiatement, et comment vérifier vos serveurs et conteneurs Docker.

Le 5 novembre 2026 à 9 h 00 UTC, OpenSSH publie un correctif. Moins d’une heure après la sortie du write-up du chercheur, un exploit fonctionnel est sur GitHub. Moins de 9 heures après la publication de la CVE, un honeypot reçoit sa première tentative. Un honeypot Alpine est compromis en root, et en moins de 40 heures les capteurs de GreyNoise exécutent les commandes des attaquants. CVE-2026-123158, surnommée *sshole (ou « SSHhole »), illustre une réalité qu’on sous-estime encore : quand une faille est triviale et qu’elle touche SSH, le délai entre divulgation et exploitation ne se compte plus en semaines, il se compte en heures.

CVE-2026-123158 en bref

• Logiciel : sshd (OpenSSH Portable) compilé avec la musl libc et sans PAM. C’est la configuration par défaut d’Alpine Linux (paquet openssh-server), et d’autres systèmes musl (OpenWrt, Buildroot, Yocto selon OX Security).
• Effet : connexion par mot de passe sur un compte qui n’a pas de mot de passe (champ * dans /etc/shadow, typiquement les comptes « clé SSH uniquement »), avec n’importe quel mot de passe trop long.
• Score : CVSS 3.1 8.1 (High), AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H. OpenSSH parle de « critical security workaround ».
• Correctif : OpenSSH 10.6p2 (5 novembre 2026) et paquets Alpine corrigés sur toutes les branches supportées.
• Découverte : Özgün Kültekin (Wakefield).
• Statut : exploits publics, exploitation réelle observée par Previdian et GreyNoise dès les 6 et 7 novembre.
• Non concernés : Debian, Ubuntu, RHEL, Fedora (glibc), tout sshd utilisant PAM, les serveurs avec PasswordAuthentication no, Dropbear, OpenBSD.

Comment fonctionne la faille SSHole : un compte sans mot de passe accepte n’importe quel mot de passe

Le mécanisme est presque comique tant il est simple, et c’est justement ce qui le rend dangereux.

1. Sur Alpine, un compte qui ne se connecte que par clé a * à la place du hash dans /etc/shadow. C’est le cas de l’utilisateur alpine des images cloud, et de root:* sur les installations récentes.
2. Depuis 2016 (correctif de CVE-2016-6210, une fuite par mesure de temps), sshd calcule quand même un hash pour ces comptes, avec le sel d’un autre compte de la machine, afin que la réponse prenne toujours le même temps.
3. La fonction crypt() de musl refuse les mots de passe de plus de 256 octets pour SHA-256/SHA-512. En cas d’échec, elle renvoie la chaîne… *.
4. sshd compare alors * (le « hash » calculé) à * (le champ de /etc/shadow). Égalité. Connexion acceptée.

Il suffit donc d’envoyer un mot de passe d’environ 257 à 1024 octets (les sources divergent légèrement sur la borne basse : 256 ou 257) vers un compte « clé uniquement », sur une machine où au moins un autre compte possède un vrai hash $5$ ou $6$. L’équipe Alpine le résume : « It takes one connection, works every time, and needs no retries ». Pas de course, pas de brute force, pas de condition de timing.

Avec glibc, crypt() ne renvoie pas cette valeur d’échec, et avec PAM la comparaison n’est pas faite ainsi : d’où le périmètre restreint. Les comptes verrouillés par ! ne sont pas touchés. OpenSSH note dans ses notes de version que « the root cause of this bug [is] outside sshd, but it is exploitable via sshd and can be avoided there » : la 10.6p2 rejette désormais les hash stockés trop courts.

Le scénario qui fait mal : image cloud Alpine, utilisateur alpine sans mot de passe, doas configuré sans mot de passe pour cet utilisateur. Une connexion SSH, une commande doas, et l’attaquant est root. Orca Security conclut : « On a default Alpine install that means root access from a single connection, so patch now. »

Chronologie de CVE-2026-123158 : de la divulgation au root en quelques heures

Voici les horodatages publiés par GreyNoise et les éditeurs, en UTC (ajoutez 1 h pour l’heure de Paris).

Date / heure (UTC)	Événement	Délai
4 nov., 21:18	Correctif écrit côté OpenSSH (non public), le signalement datant du même jour	—
5 nov., 09:00	Correctif publié dans le dépôt public, OpenSSH 10.6p2 annoncé sur oss-security ; paquets Alpine le même jour	T0
5 nov., 12:19	Write-up du chercheur publié, avec le déclencheur exact	T0 + 3 h 19
5 nov., 13:16	Premier exploit public sur GitHub	T0 + 4 h 16 (58 min après le write-up)
5 nov., 15:46	CVE-2026-123158 publiée par MITRE	T0 + 6 h 46
5 nov., 16:17	Fiche NVD, CVSS 8.1	T0 + 7 h 17
5–6 nov.	Previdian : première tentative sur son honeypot moins de 9 h après la publication de la CVE, puis root obtenu sur un honeypot Alpine réel	< T0 + 16 h
7 nov., 00:46	GreyNoise : première exploitation réussie confirmée sur ses capteurs (id; cat /etc/os-release; uname -a)	T0 + 39 h 46
7–8 nov.	16 chaînes d’exploitation réussies, 6 IP attaquantes, 7 intrusions : vol de /etc/shadow, clés SSH de persistance, implant Python	T0 + 2 à 3 jours

Retenez deux chiffres. 58 minutes : le temps entre l’explication publique du bug et un exploit prêt à l’emploi. Moins de 9 heures : le temps entre la publication de la CVE et les premières tentatives réelles. Ryan Dewhurst (Previdian) l’explique simplement : « This vulnerability was particularly trivial to exploit, which significantly shrunk that timeline. »

À ce stade, la plupart des équipes n’ont même pas encore lu le bulletin. Celles qui attendent le cycle de patch mensuel, la prochaine fenêtre de maintenance ou l’inscription au catalogue KEV de la CISA (absente au 6 novembre, d’après Help Net Security) arrivent trop tard. Le correctif et l’exploit sont sortis le même jour, les attaques ont suivi dans la nuit.

« À grande échelle » : ce que montrent vraiment les chiffres

Il faut être précis. Ce qui est massif, c’est le balayage d’Internet. Depuis la publication du correctif, GreyNoise a compté :

• 27,5 millions de scans SYN sur le port 22 ;
• 20,5 millions de connexions TCP complètes ;
• 20,1 millions de tentatives SSH ;
• et, au bout de l’entonnoir, 16 exploitations réussies (commandes shell exécutées) venant de 6 adresses IP.

Le nombre de succès reste faible pour une raison simple : peu de serveurs combinent musl, absence de PAM, mots de passe activés et un compte * exposé. Mais c’est précisément le piège. Le « bruit de fond » SSH (le même qu’on voit tous les jours, voir notre bestiaire des bots SSH observés sur honeypot) n’a qu’à ajouter un payload de 300 octets à ses tentatives pour trier automatiquement les machines vulnérables. Le coût pour l’attaquant est quasi nul ; pour la victime, c’est un root. Sur Internet, chaque Alpine exposé avec sshd par défaut sera testé, ce n’est qu’une question d’heures.

Ce que font les attaquants une fois entrés

Les sessions enregistrées par GreyNoise donnent un aperçu concret :

• Reconnaissance : id, uname -a, /etc/os-release, détection de conteneur (/.dockerenv, /var/run/docker.sock, cgroups), ip addr, mount.
• Élévation : doas -n id, lecture de /etc/doas.conf.
• Vol d’identifiants : lecture de /etc/shadow, interrogation des métadonnées cloud (169.254.169.254, 100.100.100.200) pour récupérer des jetons IAM.
• Persistance : ajout d’une clé ed25519 commentée SSHHOLE-HIT dans /home/alpine/.ssh/authorized_keys et /root/.ssh/authorized_keys. Point important : patcher après coup ne retire pas cette clé.
• Implant : un attaquant installe Python (apk add python3), dépose un « TAC Agent » dans /opt/py3/, le rend persistant via rc-update, lance un second sshd sur le port 2222 avec redirection TCP, et modifie /etc/hosts et /etc/resolv.conf.

Pourquoi patcher OpenSSH en urgence, et pas « au prochain cycle »

Damien Miller, mainteneur d’OpenSSH, n’a pas pris de gants : « stop reading and set PasswordAuthentication=no or disable SSH for these systems IMMEDIATELY ». Quatre raisons justifient ce ton :

1. Exploitation triviale et déterministe. Une seule connexion, aucune connaissance préalable, exploits publics. L’EPSS initial (≈ 1 %) ne reflète pas cette réalité : les scores prédictifs tardent toujours sur ce type de faille.
2. Service exposé par nature. SSH est souvent le seul port ouvert d’une machine d’administration. Le WAF ou le reverse proxy ne protègent rien ici.
3. Impact maximal. Accès shell, souvent root via doas, puis pivot vers le cloud via les métadonnées d’instance.
4. Fenêtre déjà fermée. Le correctif et l’exploit ont quelques heures d’écart. Le temps de « tester en préprod pendant deux semaines » n’existe pas pour ce type de faille. Une mesure de contournement en une ligne existe : il n’y a aucune excuse pour attendre.

C’est le même schéma que lors de PHP2Shell, de Node2Shell (Brotli), de wp2shell dans WordPress ou de Copy Fail dans le noyau Linux : quand le correctif est public, le diff l’est aussi, et un attaquant (ou une IA) en tire un exploit très vite. Publication du correctif = début du compte à rebours.

Suis-je concerné par CVE-2026-123158 ? Les commandes de vérification

Toutes ces conditions doivent être réunies pour être vulnérable :

# 1. sshd est-il lié à musl ? (rien = glibc, non concerné)
ldd "$(command -v sshd)" | grep -i musl

# 2. Version du paquet (comparer au tableau ci-dessous, pas à la bannière SSH)
apk info -v 2>/dev/null | grep '^openssh-server'

# 3. PAM et mots de passe
sshd -T | grep -Ei '^(usepam|passwordauthentication|permitrootlogin) '

# 4. Comptes sans mot de passe (cibles potentielles)
awk -F: '$2=="*" {print $1}' /etc/shadow

# 5. Comptes avec un vrai hash (condition nécessaire)
awk -F: '$2 ~ /^\$[56]\$/ {print $1}' /etc/shadow

Docker : un conteneur Alpine sans sshd n’est pas concerné. En revanche, toute image qui installe openssh-server sur Alpine l’est, et mettre à jour l’hôte ne corrige pas l’image : il faut la reconstruire. Cycode a testé des images populaires du Docker Hub (Gitea, Gogs, agent SSH Jenkins, linuxserver/openssh-server) : la plupart désactivent les mots de passe par défaut, mais pas toutes, et linuxserver/openssh-server devient vulnérable avec PASSWORD_ACCESS=true. Les images Alpine antérieures à 3.16 n’auront pas de correctif.

Pour un parc de conteneurs, une boucle rapide :

for c in $(docker ps -q); do
  echo "$(docker inspect -f '{{.Name}}' $c): $(docker exec $c sh -c \
    'grep -h ^ID= /etc/os-release; command -v sshd' 2>/dev/null | tr '\n' ' ')"
done

Corriger SSHole : OpenSSH 10.6p2 et paquets Alpine

Branche Alpine	Paquet openssh corrigé
edge	10.6_p2-r0
3.24	10.3_p1-r2
3.23	10.2_p1-r1
3.22	10.0_p1-r11
3.21	9.9_p2-r1
3.20	9.7_p1-r6
3.19	9.6_p1-r3
3.18	9.3_p2-r4
3.17	9.1_p1-r7
3.16	9.0_p1-r6

Les branches 3.16 à 3.20 sont hors support : le paquet existe, mais il faut planifier la migration. Les rétroportages conservent l’ancien numéro de version OpenSSH : vérifiez la révision du paquet (-rX), pas la bannière.

# Mise à jour + redémarrage du démon (indispensable : l'ancien sshd reste en mémoire)
apk upgrade -U -a
rc-service sshd restart

Contournement immédiat si vous ne pouvez pas mettre à jour

# Alpine 3.19+ (drop-in lu en premier)
echo 'PasswordAuthentication no' > /etc/ssh/sshd_config.d/00-no-passwords.conf
sshd -t && rc-service sshd restart

# Vérification : doit afficher "passwordauthentication no"
sshd -T | grep -i passwordauthentication

Trois précautions : gardez une session SSH ouverte et testez votre clé avant de couper les mots de passe ; vérifiez qu’aucun bloc Match ne réactive PasswordAuthentication ; et ne « verrouillez » pas les comptes avec ! pour vous en sortir : sur un sshd sans PAM, cela bloque aussi l’authentification par clé. En complément, restreignez le port 22 à vos IP de confiance (firewall, CrowdSec, fail2ban, VPN) ou placez vos services derrière un point d’entrée unique comme Pangolin.

J’ai patché : ai-je été compromis ? Détection et indicateurs

Si une machine vulnérable a été exposée après le 5 novembre, considérez qu’elle a été testée. Vérifiez :

# Connexions par mot de passe sur des comptes "clé uniquement"
grep 'sshd.*Accepted password for' /var/log/messages*

# Usage de doas
grep doas /var/log/messages*

# Clés SSH ajoutées (marqueur observé : SSHHOLE-HIT)
grep -r 'SSHHOLE-HIT' /root/.ssh /home/*/.ssh 2>/dev/null
ls -la /root/.ssh/authorized_keys /home/*/.ssh/authorized_keys

# Implant et persistance observés par GreyNoise
ls -la /opt/py3/ 2>/dev/null; rc-update show | grep -i tac
grep -i vpnla /etc/hosts; ss -tlnp | grep 2222

Indicateurs publiés par GreyNoise : domaine C2 tac.vpnla.org (port 8443, à bloquer par nom plutôt que par IP, l’adresse étant partagée), fichier /opt/py3/tac_agent.py (SHA-256 55e6384f6d1648be9b48fb899e46623e9c05eb0df2cbf95f6701680d4e7cbc2a), IP sources notamment 20.255.63.133, 183.220.91.15, 209.248.50.17, 79.116.138.30, 20.2.81.241, 47.80.65.43, et 89.116.89.18 pour les tentatives relevées par Previdian. Ces IP changeront : la vraie protection reste le correctif.

En cas de compromission avérée : isolez la machine, faites tourner tous les secrets qu’elle détenait (clés SSH, jetons cloud, mots de passe présents dans /etc/shadow), et réinstallez plutôt que de nettoyer.

FAQ : SSHole (CVE-2026-123158)

Mon serveur Debian ou Ubuntu est-il vulnérable à CVE-2026-123158 ?
Non. Ces distributions utilisent glibc et PAM. Seuls les sshd liés à musl sans PAM sont concernés.

Mes conteneurs Docker Alpine sont-ils à risque ?
Uniquement s’ils exécutent un serveur OpenSSH avec l’authentification par mot de passe active. Reconstruisez ces images sur un paquet corrigé ; la mise à jour de l’hôte ne suffit pas.

La faille est-elle exploitée ?
Oui. Previdian a observé des tentatives moins de 9 heures après la publication de la CVE et un accès root sur honeypot ; GreyNoise a confirmé 16 exploitations réussies entre le 7 et le 8 novembre 2026.

Désactiver PasswordAuthentication suffit-il ?
Oui comme contournement immédiat, à condition de vérifier avec sshd -T qu’aucun bloc Match ne le réactive. Mettez à jour ensuite.

Quelle version d’OpenSSH corrige SSHole ?
OpenSSH 10.6p2, publiée le 5 novembre 2026. Sur Alpine, installez le paquet corrigé de votre branche (par exemple 10.3_p1-r2 sur 3.24) puis redémarrez sshd.

Sources

• OpenSSH – notes de version 10.6p2
• GreyNoise – suivi de l’activité SSHole
• Help Net Security – exploitation quelques heures après la divulgation
• Orca Security – analyse technique
• Cycode – tests sur images Docker Hub
• OX Security
• Konfirmity – avis détaillé et commandes
• Tenable – fiche CVE
• BleepingComputer