SSHole – CVE-2026-123158

Le 5 novembre 2026, le projet OpenSSH publie la version 10.6p2 de son édition portable, présentée comme une parade de sécurité critique. Elle bloque un contournement de l’authentification par mot de passe dans le serveur sshd, baptisé sshole par son découvreur, Özgün Kültekin, de la société Wakefield. La CVE (1) CVE-2026-123158 est publiée le même jour à 15:46 UTC (2) par MITRE, en qualité de CNA (3).

Le défaut concerne les systèmes Linux dont la bibliothèque C est musl et dont le serveur SSH (4) vérifie les mots de passe sans passer par PAM (5). Alpine Linux en est l’exemple principal : son paquet openssh-server est compilé sans PAM, et l’authentification par mot de passe reste active par défaut. Sur ces systèmes, un compte sans mot de passe, c’est-à-dire un compte dont le champ de mot de passe vaut * dans /etc/shadow, accepte n’importe quel mot de passe de 257 à 1 024 octets dès qu’un autre compte local possède un hash SHA (6) de type $5$ ou $6$. Sont visés les comptes réservés à l’authentification par clé, les utilisateurs issus d’un annuaire et, sur les images cloud officielles d’Alpine, l’utilisateur alpine, qui peut devenir root par doas sans mot de passe.

L’avis d’Alpine Linux décrit une attaque en une seule connexion, réussie à chaque tentative, sans nouvel essai. La fiche CVE retient un score CVSS (7) 3.1 de 8,1, sévérité élevée, avec une complexité d’attaque élevée ; OpenSSH emploie le qualificatif « critique » sans publier de score. Le projet situe la cause racine hors de sshd, dans le comportement de la fonction crypt() de musl, mais livre le correctif dans sshd, où le défaut est exploitable.

Ne sont pas concernés, selon OpenSSH, Alpine et le chercheur : les systèmes autres que Linux, les distributions Linux à base de glibc comme Debian, Ubuntu ou Fedora, les systèmes qui vérifient les mots de passe par PAM, ainsi que le serveur SSH Dropbear.

Le défaut naît de la rencontre de choix techniques indépendants, pris par deux projets à quatre ans d’intervalle, puis d’un changement de configuration d’Alpine en 2022. Le chercheur en reconstitue l’historique sur sshhole.com et dans le dépôt GitHub qui accompagne sa publication.

Fig. 1. Chronologie reconstituée à partir des notes de version d’OpenSSH, de l’annonce de Damien Miller, de l’avis d’Alpine Linux, de la fiche CVE, de sshhole.com et du fichier TIMELINE.md du dépôt oz9un/sshole, de The Hacker News et de Help Net Security.

Un écart d’un jour subsiste sur la date du signalement. Le chercheur le date du 3 novembre ; dans son message du 5 novembre, Damien Miller indique que l’équipe a pris connaissance du problème « hier ». L’avis d’Alpine et l’article de The Hacker News du 5 novembre indiquent qu’aucun identifiant CVE n’était attribué au moment de leur rédaction ; la fiche a été publiée le même jour.

Méthode de découverte

Le chercheur indique avoir compilé sshd dans toutes les combinaisons envisageables (glibc ou musl, avec ou sans PAM, avec ou sans fichier shadow) et avoir soumis à ces compilations environ 17 600 tentatives de connexion atypiques : hash malformés, comptes incohérents, mots de passe très longs. Toutes les compilations ont rendu la même décision pour chaque tentative, à l’exception de la compilation musl sans PAM. Il précise avoir travaillé avec des essaims d’agents d’IA (11). Son dépôt mentionne un banc de test de 17 environnements, dont une image cloud sous QEMU, OpenWrt, Buildroot et des utilisateurs d’annuaire, dont le détail n’est pas publié.

Les notes de version d’OpenSSH 10.6p1 et 10.6p2 relèvent que des failles identifiées par des outils d’IA sont ensuite redécouvertes de façon indépendante par d’autres chercheurs, et annoncent des publications plus fréquentes. Damien Miller ajoute que l’équipe considère désormais les longues périodes d’embargo comme une pratique dangereuse, profitant surtout aux attaquants, après plusieurs cas de redécouverte rapide par des agents d’IA, parfois en quelques heures.

Crédits

Le signalement est attribué à Özgün Kültekin, de Wakefield. Alpine remercie Damien Miller et Darren Tucker, d’OpenSSH, pour le correctif et la version 10.6p2, Timo Teräs pour l’aide à l’analyse et Natanael Copa pour la construction et la mise en ligne des paquets.

Compilé sans PAM, sshd vérifie lui-même un mot de passe dans la fonction sys_auth_passwd() : il calcule le hash du mot de passe soumis avec crypt(), en reprenant le sel du hash stocké, puis compare le résultat au champ stocké par strcmp(). L’égalité vaut authentification. Un compte sans mot de passe porte * dans ce champ ; aucun hash ne pouvant valoir *, ce compte refuse en principe toute authentification par mot de passe.

Le champ * est trop court pour contenir un sel. Depuis la correction de la CVE-2016-6210 en 2016, sshd emprunte alors, par la fonction pick_salt(), le sel d’un autre compte du système dont le hash commence par $, afin que le temps de réponse ne révèle pas l’absence de hash utilisable. Le mot de passe soumis est donc haché avec le sel d’un compte tiers, puis comparé à *.

Pour les types $5$ (SHA-256) et $6$ (SHA-512), la fonction crypt() de musl refuse toute clé de plus de 256 octets et renvoie la chaîne * comme indicateur d’erreur. Cette chaîne est identique au champ stocké du compte sans mot de passe : strcmp() conclut à l’égalité et sshd accepte la connexion. La borne haute de 1 024 octets est la longueur maximale de mot de passe acceptée par sshd, fixée par la constante MAX_PASSWORD_LEN.

Fig. 2. Enchaînement décrit par l’avis d’Alpine Linux et par le dépôt oz9un/sshole, recoupé avec le code modifié par le commit 4353fdc.

Pourquoi les autres configurations échappent au défaut

• avec PAM, la vérification passe par le module de PAM, qui, selon le chercheur, n’appelle pas crypt() pour un champ *
• avec glibc, les distributions passent par PAM ; le chercheur relève par ailleurs que libxcrypt, adoptée par Debian, renvoie *0 en cas d’échec, valeur qui ne correspond pas à *
• un compte verrouillé par ! ne correspond pas à * et reste fermé, d’après l’avis d’Alpine
• sans aucun hash de type $ sur la machine, aucun sel $5$ ou $6$ ne peut être repris, et le calcul ne passe pas par les fonctions SHA de musl qui portent la limite de 256 octets ; l’avis d’Alpine exclut ces systèmes, et le chercheur précise qu’un système neuf sans mot de passe défini n’est pas exposé

L’avis d’Alpine pose quatre conditions cumulatives sur la machine, auxquelles s’ajoute l’exigence côté attaquant d’un accès réseau au port SSH et du nom d’un compte sans mot de passe. Un seul compte doté d’un mot de passe suffit à rendre accessibles tous les comptes qui n’en ont pas.

Fig. 3. Conditions d’exposition selon l’avis d’Alpine Linux du 5 novembre 2026, complétées par le dépôt oz9un/sshole pour le verrouillage par !.

Comptes visés

• root, livré en root:* dans l’image de base depuis Alpine 3.16 environ ; la valeur par défaut PermitRootLogin prohibit-password le protège, sauf si PermitRootLogin yes est positionné. Cette protection ne vaut pas si un autre compte exposé peut devenir root, par exemple par doas
• les comptes réservés à l’authentification par clé, créés par adduser sans mot de passe ou par usermod -p '*'
• les utilisateurs issus d’un annuaire par musl-nscd (nslcd, winbind, sssd), qui n’ont pas d’entrée dans le fichier shadow
• l’utilisateur alpine des images cloud officielles tiny-cloud, doté d’un doas sans mot de passe

Images cloud tiny-cloud

Les images tiny-cloud officielles des versions 3.18.11 à 3.24.3 livrent un utilisateur alpine au champ *, autorisé à utiliser doas sans mot de passe. Elles ne sont pas exposées au premier démarrage. Elles le deviennent dès qu’un hash $6$ existe sur la machine, par exemple lorsqu’un administrateur définit un mot de passe de console ou que les données utilisateur créent un compte avec hashed_passwd. L’attaquant obtient alors un shell sous alpine, puis les droits root par doas. Le chercheur et Cyber Press citent les images officielles pour Amazon Web Services et Azure. Les images construites à partir des versions 3.21.10, 3.22.8, 3.23.8, 3.24.4 et suivantes intègrent le paquet corrigé ; les instances lancées depuis une image antérieure doivent être mises à jour individuellement.

Au-delà d’Alpine

Le chercheur cite d’autres systèmes à base de musl à examiner : OpenWrt, Buildroot, Yocto, postmarketOS, Void dans sa variante musl et Chimera. OpenWrt utilise Dropbear par défaut ; le défaut n’y concerne que les installations où un administrateur a ajouté le serveur OpenSSH, comme le relève The Hacker News. TheCyberThrone étend l’inventaire aux instances cloud, aux conteneurs, aux équipements réseau et aux environnements Linux embarqués.

Pour les conteneurs, l’avis d’Alpine précise que ceux qui n’exécutent pas sshd ne sont pas concernés. Le chercheur rappelle que de nombreuses images Docker reposent sur musl ; l’exposition dépend de la présence d’un sshd en écoute. Cyber Press souligne de même que l’usage d’une distribution musl ou d’un conteneur Alpine ne suffit pas à établir l’exposition.

Le dépôt du chercheur indique que la PoC (12) fonctionne au moins jusqu’à Alpine 3.18, et que la plus ancienne combinaison testée, OpenSSH 7.5p1 sur musl 1.1.16 en 2017, est également vulnérable. Le défaut existe depuis l’introduction de l’emprunt de sel dans OpenSSH 7.3p1, en 2016.

Impact

L’attaquant obtient une session avec les droits du compte visé, dans les limites des contrôles d’accès propres à sshd. Le contournement ne touche ni au chiffrement du protocole ni aux mots de passe existants. Sur les images tiny-cloud vulnérables, le compte alpine donne accès aux droits root ; sur une machine où PermitRootLogin yes est positionné, le compte root est directement accessible.

La fiche CVE déclare affecté OpenSSH avant la version 10.6p2 sur la plateforme Linux, avec un statut par défaut « unaffected » pour les autres versions. Sa description restreint le défaut aux systèmes utilisant musl sans PAM. La faiblesse retenue est la CWE (13) 394, valeur de retour ou code d’état inattendu. La fiche porte le vecteur CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H, score 8,1.

Paquets corrigés d’Alpine Linux

Fig. 4. Versions corrigées du paquet openssh par branche, d’après l’avis d’Alpine Linux du 5 novembre 2026. Les versions de point 3.21.10, 3.22.8, 3.23.8 et 3.24.4 contiennent le paquet corrigé.

La mise à jour se fait par apk upgrade -U -a, suivie du redémarrage du service par rc-service sshd restart. Pour une compilation à partir des sources, la version 10.6p2 d’OpenSSH porte la modification ; le chercheur fournit le correctif amont inchangé dans son dépôt et indique qu’il s’applique à toutes les versions depuis 7.3p1.

Le commit 4353fdc, intitulé « avoid password authn bypass », modifie trois fichiers : auth-passwd.c, openbsd-compat/port-uw.c et openbsd-compat/xcrypt.c, pour 34 lignes ajoutées et 17 supprimées. Son message reprend la position du projet : la cause racine n’est pas jugée interne à OpenSSH, mais le projet est en mesure de l’éviter.

• une constante MIN_PASSWORD_HASH_LEN, fixée à 4, est introduite dans auth-passwd.c : la comparaison n’aboutit que si le champ stocké compte au moins quatre caractères, ce qui exclut *
• shadow_pw() renvoie désormais une copie du champ de mot de passe, obtenue par xstrdup(), au lieu d’un pointeur vers le tampon statique de la bibliothèque C ; la copie est effacée par freezero() après usage
• pick_salt() libère et efface chaque copie intermédiaire lors du parcours des comptes

Le chercheur résume l’effet : sshd ne procède plus à la comparaison lorsque le champ stocké est trop court pour être un hash réel, et cesse d’utiliser un pointeur vers le tampon statique de la bibliothèque C. Les paquets des branches stables d’Alpine portent un correctif traitant le même problème.

La version 10.6p2 intègre aussi des corrections fonctionnelles déjà présentes sur la branche stable V_10_6, dont l’acceptation de l’algorithme de signature hybride post-quantique ssh-mldsa44-ed25519 comme algorithme de signature d’autorité de certification et la correction d’une consommation processeur liée à ChannelTimeout.

OpenSSH, Alpine et le chercheur convergent : désactiver l’authentification par mot de passe ferme entièrement le chemin d’attaque. Damien Miller demande de positionner PasswordAuthentication=no ou de désactiver SSH immédiatement sur les systèmes concernés. L’avis d’Alpine détaille la procédure, à exécuter en tant que root après avoir vérifié que l’authentification par clé fonctionne, en conservant la session ouverte jusqu’au succès d’une nouvelle connexion :

• mkdir -p /etc/ssh/sshd_config.d
• echo 'PasswordAuthentication no' > /etc/ssh/sshd_config.d/00-no-passwords.conf
• sed -i.bak -e '1i PasswordAuthentication no' -e 's/^\(\s*PasswordAuthentication[^y#]*\)yes/\1no/i' /etc/ssh/sshd_config
• sshd -t && rc-service sshd restart
• sshd -T | grep -i passwordauthentication, qui doit afficher passwordauthentication no

Le fichier de configuration complémentaire n’est lu par la configuration par défaut d’Alpine qu’à partir de la version 3.19 ; les versions antérieures l’ignorent, d’où la commande sed. Celle-ci remplace yes par no sur chaque ligne PasswordAuthentication de /etc/ssh/sshd_config, y compris dans un bloc Match, ajoute la directive en tête de fichier et conserve l’original sous /etc/ssh/sshd_config.bak. Pour revenir en arrière, supprimer /etc/ssh/sshd_config.d/00-no-passwords.conf et restaurer /etc/ssh/sshd_config.bak.

TheCyberThrone ajoute la restriction de l’accès SSH à des sources réseau de confiance et la revue des comptes destinés à l’authentification par clé seule. Le verrouillage de ces comptes par ! n’est pas une alternative sur un système sans PAM : il bloque aussi l’authentification par clé, raison pour laquelle Alpine avait abandonné cette valeur pour root en 2022.

La divulgation s’est faite sans embargo long. Selon le chercheur, le défaut est signalé le 3 novembre, Alpine et musl sont prévenus le 4, et la version corrigée paraît le 5 novembre, en même temps que les paquets d’Alpine et la page explicative sshhole.com. Le dépôt du chercheur publie le même jour un script de vérification, une PoC reproductible dans un conteneur Docker et le correctif. La PoC envoie un premier mot de passe quelconque, puis une chaîne de 300 caractères ; le script attack.py montre le refus à 256 caractères et le succès à 257.

Les constats sur l’exploitation diffèrent selon la date et la source, et sont à tenir séparés :

• le 5 novembre, The Hacker News indique qu’aucune attaque exploitant le défaut n’a été rapportée
• le 6 novembre, Help Net Security rapporte les observations de Previdian : une première tentative moins de neuf heures après la publication de la CVE, puis un accès root confirmé sur un honeypot exécutant une installation réelle d’Alpine et d’OpenSSH ; huit tentatives au total, toutes depuis une même adresse IP (15) située au Japon et captées par un seul capteur
• selon Previdian, l’attaquant a utilisé des mots de passe surdimensionnés, puis lancé les commandes de reconnaissance id, uname et hostname dans des sessions SSH non interactives
• Previdian a inscrit la vulnérabilité dans son propre catalogue de vulnérabilités exploitées ; la CISA ne l’avait pas inscrite à son catalogue KEV (16) selon Help Net Security
• l’évaluation SSVC de la CISA dans la fiche CVE, mise à jour le 6 novembre à 04:56 UTC, retient une exploitation au stade de la PoC, une exploitation non automatisable et un impact technique total
• des PoC sont publiées sur GitHub ; la fiche CVE référence deux dépôts de reproduction en plus de celui du chercheur. Previdian avertit que des PoC publiées sur GitHub ne sont pas vérifiées et peuvent contenir des malwares
• aucune attribution à un acteur n’a été rendue publique

Vérifier l’exposition d’une machine

Le script check.sh du dépôt oz9un/sshole contrôle les cinq conditions : bibliothèque C, compilation de sshd avec ou sans PAM, valeur de PasswordAuthentication, comptes au champ * et présence d’un hash $5$ ou $6$. Il indique la condition manquante lorsque la machine n’est pas exposée. Les mêmes contrôles peuvent être menés à la main sur Alpine, en tant que root :

• version du paquet installé, à comparer à la figure 4 : apk info -v openssh
• variante du serveur installée : apk info -e openssh-server openssh-server-pam
• valeur effective de l’authentification par mot de passe : sshd -T | grep -i passwordauthentication
• comptes au champ * : awk -F: '$2=="*"{print $1}' /etc/shadow
• comptes dotés d’un hash $5$ ou $6$ : awk -F: '$2 ~ /^\$[56]\$/{print $1}' /etc/shadow

Les utilisateurs issus d’un annuaire par musl-nscd n’ont pas d’entrée dans /etc/shadow et n’apparaissent donc pas dans ces listes, alors qu’ils sont exposés selon l’avis d’Alpine.

Rechercher une compromission

L’avis d’Alpine recommande de rechercher dans /var/log/messages les lignes de sshd de la forme Accepted password for portant sur un compte sans mot de passe, comme alpine, root ou un compte réservé à l’authentification par clé, par exemple avec grep 'Accepted password for' /var/log/messages. Sur les machines exposées, il recommande aussi de revoir l’usage de doas, les comptes, fichiers et clés autorisées récemment créés. Si une connexion ne peut être exclue, la machine est à traiter comme compromise. Le mot de passe surdimensionné circule dans le canal chiffré de SSH : sa longueur n’est pas observable sur le réseau, et la recherche repose sur les journaux de la machine.

Indicateurs publiés

Fig. 5. Indicateurs rendus publics au 6 novembre 2026. L’adresse est neutralisée par crochets.

Les notes de version et le commit d’OpenSSH, l’annonce de Damien Miller, l’avis d’Alpine Linux, la fiche CVE, sshhole.com et le dépôt du chercheur sont des sources primaires, lues en intégralité. The Hacker News, Help Net Security, Cyber Press et TheCyberThrone sont des sources de presse spécialisée ; la discussion Reddit est une source communautaire.

1. CVE (1) : Common Vulnerabilities and Exposures, identifiant public attribué à une vulnérabilité.
2. UTC (2) : Coordinated Universal Time, temps universel coordonné.
3. CNA (3) : CVE Numbering Authority, organisme habilité à attribuer des CVE et à publier leur fiche ; ici MITRE.
4. SSH (4) : Secure Shell, protocole d’administration et de transfert de fichiers à distance, chiffré.
5. PAM (5) : Pluggable Authentication Modules, interface modulaire d’authentification des systèmes Unix et Linux.
6. SHA (6) : Secure Hash Algorithm, famille de fonctions de hachage ; les types $5$ et $6$ de crypt() reposent sur SHA-256 et SHA-512.
7. CVSS (7) : Common Vulnerability Scoring System, système de notation de la gravité des vulnérabilités.
8. ADP (8) : Authorized Data Publisher, organisme autorisé à enrichir une fiche CVE de données complémentaires.
9. CISA (9) : Cybersecurity and Infrastructure Security Agency, agence américaine de cybersécurité et de sécurité des infrastructures.
10. SSVC (10) : Stakeholder-Specific Vulnerability Categorization, méthode de priorisation des vulnérabilités fondée sur des points de décision.
11. IA (11) : intelligence artificielle.
12. PoC (12) : Proof of Concept, code démontrant la faisabilité d’une exploitation.
13. CWE (13) : Common Weakness Enumeration, classification des faiblesses logicielles.
14. CPE (14) : Common Platform Enumeration, nomenclature normalisée des produits et versions, utilisée par les outils de gestion des vulnérabilités.
15. IP (15) : Internet Protocol, protocole d’adressage du réseau Internet.
16. KEV (16) : Known Exploited Vulnerabilities, catalogue de la CISA des vulnérabilités dont l’exploitation est constatée.

1. OpenSSH, OpenSSH 10.6p2 Release Notes, 5 novembre 2026. openssh.org/releasenotes
2. Damien Miller, urgent security release: 10.6p2, liste openssh-unix-dev, 5 novembre 2026. marc.info
3. OpenSSH Portable, commit avoid password authn bypass, 4353fdc, 5 novembre 2026. github.com/openssh/openssh-portable
4. Alpine Linux, Security advisory: openssh-server password authentication bypass, 5 novembre 2026. alpinelinux.org
5. CVE Program, fiche CVE-2026-123158, CNA MITRE, publiée le 5 novembre 2026, mise à jour le 6 novembre 2026, enregistrement JSON du dépôt cvelistV5. github.com/CVEProject/cvelistV5
6. Özgün Kültekin, *sshole, 5 novembre 2026. sshhole.com
7. Özgün Kültekin, dépôt oz9un/sshole : README, TIMELINE.md, check.sh, PoC et correctif, novembre 2026. github.com/oz9un/sshole
8. The Hacker News, Swati Khandelwal, OpenSSH Issues Emergency Fix for Flaw Letting Long Passwords Bypass SSH Auth on Alpine Linux, 5 novembre 2026. thehackernews.com
9. Help Net Security, Sinisa Markovic, OpenSSH flaw exploited in the wild just hours after disclosure (CVE-2026-123158), 6 novembre 2026. helpnetsecurity.com
10. Cyber Press, Tamilselvan, Critical OpenSSH Authentication Bypass Lets Hackers Log In Without Knowing Passwords, 6 novembre 2026. cyberpress.org
11. TheCyberThrone, PravinKarthik, SSHole: OpenSSH Authentication Bypass, CVE-2026-123158, 6 novembre 2026. thecyberthrone.in
12. Reddit, r/cybersecurity, discussion relayant un article de BleepingComputer, 6 novembre 2026. reddit.com/r/cybersecurity