Suivre Une vulnérabilité de haute gravité dans OpenSSH peut permettre à des attaquants distants non authentifiés de contourner l’authentification par mot de passe sur certains systèmes Linux en soumettant un mot de passe trop long. Suivie sous le nom CVE-2026-123158 et surnommée SSHhole, la faille a un score CVSS 3.1 de 8.1 et impacte principalement les environnements Linux où sshd est lié contre musl libc et fonctionne sans PAM. Alpine Linux est la plateforme la plus affectée car son package standard openssh-server utilise cette configuration par défaut.
La vulnérabilité résulte d’une interaction inattendue entre la validation du mot de passe OpenSSH et l’implémentation de crypt() par musl libc. Lorsqu’un mot de passe excessivement long est fourni, crypt() peut renvoyer la chaîne * pour indiquer une erreur. Certains comptes Linux qui ne sont pas configurés avec un mot de passe conventionnel stockent également * dans le champ de mot de passe de /etc/shadow. Dans des conditions vulnérables, sshd peut incorrectement interpréter les valeurs correspondantes comme une authentification réussie.
Un attaquant n’a pas besoin de connaître le mot de passe de l’utilisateur cible. Si un service SSH exposé remplit les conditions requises, un attaquant qui peut atteindre le service peut s’authentifier à certains comptes en utilisant un mot de passe de la longueur vulnérable. L’impact dépend des privilèges attribués au compte compromis. L’accès à un compte de service privilégié ou à un compte capable d’utiliser doas ou un autre mécanisme d’escalade de privilèges pourrait mener à une compromission complète du système.
OpenSSH a abordé le problème dans Portable OpenSSH 10.6p2, publié le 5 novembre 2026. Alpine Linux a simultanément publié des paquets OpenSSH corrigés pour toutes les branches prises en charge et plusieurs anciennes branches. L’équipe OpenSSH décrit cette version comme contenant une solution de contournement de sécurité critique pour les systèmes Linux utilisant musl libc avec PAM désactivé.
Des environnements de reproduction publique et des matériaux de preuve de concept sont déjà disponibles. Cependant, au 6 novembre 2026, les sources examinées ne signalent pas d’exploitation confirmée de la vulnérabilité dans des attaques du monde réel, et la faille n’a pas été ajoutée au catalogue des vulnérabilités exploitées connues de la CISA.
Les organisations peuvent renforcer leurs défenses contre les vulnérabilités émergentes de contournement de l’authentification avec la plateforme AI-Native Detection Intelligence de SOC Prime, accélérant la chasse aux menaces et l’ingénierie de détection dans les environnements SIEM, EDR, XDR et Data Lake.
Les équipes de sécurité peuvent également utiliser Prime Architect pour transformer l’intelligence des vulnérabilités en requêtes de chasse et en logique de détection adaptées à leur télémétrie SSH, d’authentification, de point de terminaison et de réseau disponibles.
Détectez CVE-2026-123158 en surveillant les connexions SSH réussies basées sur un mot de passe vers des comptes utilisant normalement uniquement l’authentification par clé, des tentatives d’authentification inhabituelles contenant des mots de passe anormalement longs, un accès à distance inattendu aux comptes de service et une activité post-authentification incohérente avec le comportement normal du compte.
Le contenu de détection peut ne pas être disponible pour chaque CVE. Vérifiez la plateforme SOC Prime pour la couverture actuelle. Si des détections pertinentes ne sont pas encore disponibles, vérifiez à nouveau car de nouvelles informations sur les menaces et du contenu de détection sont continuellement ajoutés.
Analyse CVE-2026-123158
CVE-2026-123158 affecte OpenSSH sshd avant Portable OpenSSH 10.6p2 lorsqu’il fonctionne sur Linux avec musl libc et que l’authentification par mot de passe se fait sans PAM. Le CVE a un score CVSS 3.1 de 8.1 avec le vecteur AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H, reflétant une exploitation à distance sans privilèges préalables ni interaction utilisateur mais nécessitant une configuration système et de compte spécifique.
La cause principale réside dans l’interaction entre OpenSSH et la fonction de hachage de mot de passe fournie par musl libc.
Sur les systèmes où PAM est désactivé, sshd effectue la validation des mots de passe en utilisant la fonctionnalité crypt() du système. Pour un compte typique, /etc/shadow contient un hachage cryptographique de mot de passe, et la valeur générée à partir du mot de passe soumis par l’utilisateur est comparée à ce hachage stocké.
musl libc se comporte différemment lorsque le mot de passe fourni dépasse sa longueur d’entrée prise en charge. Pour les mots de passe de plus de 256 octets, crypt() renvoie * en tant que valeur d’erreur plutôt qu’un hachage de mot de passe normal.
Le problème survient parce que * est également couramment utilisé dans /etc/shadow pour les comptes qui n’ont pas de mot de passe traditionnel configuré.
Si un sshd vulnérable reçoit un mot de passe trop long pour l’un de ces comptes, le flux d’authentification peut effectivement comparer le * renvoyé par crypt() avec le * stocké dans l’entrée shadow du compte. Les valeurs correspondent, et l’authentification peut incorrectement réussir.
La description du CVE indique que, pour les configurations de compte affectées, les mots de passe entre 256 et 1024 caractères peuvent aboutir à une authentification réussie. Les reproductions indépendantes décrivent des mots de passe dépassant la limite normale de 256 octets comme suffisants pour déclencher la condition vulnérable.
La faille n’est donc pas un contournement universel de mot de passe affectant chaque déploiement OpenSSH.
Plusieurs conditions spécifiques doivent être réunies.
Tout d’abord, le serveur doit utiliser musl libc. Alpine Linux est le principal exemple grand public, bien que d’autres environnements Linux embarqués ou minimaux puissent également utiliser musl.
Deuxièmement, sshd doit authentifier les utilisateurs sans PAM. Le package standard openssh-server d’Alpine est construit sans PAM, tandis que la configuration alternative openssh-server-pam est protégée lorsque UsePAM yes est activé.
Troisièmement, l’authentification par mot de passe doit être activée. PasswordAuthentication yes est la configuration pertinente. Les systèmes configurés pour l’authentification par clé publique uniquement avec PasswordAuthentication no ne sont pas exposés au chemin d’attaque documenté.
Enfin, l’attaquant a besoin d’un compte dont le champ de mot de passe contient *. Cela peut inclure des utilisateurs par clé uniquement, des comptes créés sans mot de passe, certaines identités fournies par des services d’annuaire, et certains utilisateurs d’images cloud.
Alpine note également une condition supplémentaire : au moins un compte local doit contenir un hachage de mot de passe à style $5$ ou $6$ pour que le chemin d’authentification vulnérable fonctionne tel que décrit.
Le compte root mérite une attention particulière. Alpine stocke couramment root:*, mais le PermitRootLogin prohibit-password par défaut d’OpenSSH empêche l’authentification par mot de passe directe vers root. En conséquence, une installation standard d’Alpine n’expose pas automatiquement l’accès root direct par ce bug.
Cette protection n’élimine pas le risque plus large. Si un autre compte avec * dans son champ de mot de passe est accessible à distance et dispose de droits administratifs via doas, sudo, des capacités de conteneur ou d’autres mécanismes privilégiés, une authentification réussie peut encore fournir un chemin à une compromission complète du système.
Les images tiny-cloud officielles d’Alpine sont particulièrement pertinentes. Une recherche en sécurité a identifié des versions où le compte alpine pouvait remplir les conditions vulnérables et pouvait également utiliser doas pour obtenir des privilèges élevés. Cela illustre pourquoi les défenseurs doivent évaluer les privilèges des comptes plutôt que de supposer que la vulnérabilité offre un accès utilisateur inoffensif ou un accès root automatique dans chaque environnement.
Les distributions Linux basées sur glibc telles que Debian, Ubuntu et RHEL ne sont pas affectées par cette vulnérabilité spécifique car le comportement vulnérable dépend de l’implémentation de hachage de mot de passe de musl libc. Les systèmes utilisant PAM pour la validation des mots de passe SSH ne sont également pas dans la configuration vulnérable documentée.
Les conteneurs nécessitent une qualification similaire. Alpine est largement utilisé comme image de base de conteneur, mais les conteneurs ordinaires qui n’exécutent pas sshd ne sont pas vulnérables par ce chemin d’attaque. La préoccupation principale concerne les conteneurs, les appareils, les environnements de développement ou les charges de travail héritées qui installent et exposent explicitement un serveur SSH.
Le paysage des PoC pour CVE-2026-123158 a évolué rapidement. Les laboratoires de reproduction publique sont directement référencés par l’enregistrement de la vulnérabilité, démontrant que les défenseurs doivent supposer que le contournement d’authentification peut être reproduit sans accès à la recherche d’exploitation privée. Cela augmente matériellement l’urgence de la remédiation même si aucune exploitation malveillante confirmée n’a encore été signalée.
La vulnérabilité a été signalée par Özgün Kültekin de Wakefield. OpenSSH a publié publiquement la version 10.6p2 avec la solution de contournement de sécurité le 5 novembre 2026. Les sources primaires examinées ne spécifient pas la date exacte à laquelle le chercheur a initialement découvert ou signalé en privé le problème.
Le correctif OpenSSH ajoute une validation conçue pour empêcher les valeurs d’erreur et les hachages de mot de passe courts invalides d’être acceptés lors de l’authentification par mot de passe. OpenSSH note qu’il considère que la cause sous-jacente se trouve en dehors de sshd, mais parce que la condition peut être exploitée via le serveur SSH, le projet a mis en place une solution défensive dans OpenSSH lui-même.
Alpine Linux a rétroporté la correction sur plusieurs branches :
| Branche Alpine | Package 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 administrateurs doivent se fier à l’état du paquet de distribution plutôt qu’à la bannière de version SSH seule. Les distributions Linux rétroportent fréquemment des correctifs de sécurité sans changer la version OpenSSH affichée lors de la poignée de main SSH. Un serveur affichant une ancienne chaîne de version peut donc déjà contenir le correctif du fournisseur.
Pour la détection de CVE-2026-123158, les défenseurs doivent prioriser la télémétrie d’authentification SSH. Un signal de chasse particulièrement fort est une connexion par mot de passe réussie à un compte censé utiliser uniquement l’authentification par clé publique ou qui n’a pas de mot de passe utilisable configuré.
Sur les systèmes Alpine, les administrateurs peuvent examiner /var/log/messages, les journaux d’authentification centralisés, les enregistrements SIEM, ou une télémétrie équivalente pour les événements de mot de passe accepté impliquant des comptes de services, des comptes par clé seulement, ou des comptes administratifs inattendus.
Les défenseurs doivent corréler l’authentification réussie avec les adresses IP source, les heures de connexion, la durée de session, les commandes exécutées après l’authentification, l’élévation des privilèges, les modifications de authorized_keys, la création de comptes, les tâches planifiées, et les connexions sortantes inattendues.
La télémétrie réseau peut également aider à identifier les systèmes exposés. Les services SSH accessibles depuis l’extérieur qui annoncent l’authentification par mot de passe ou interactive par clavier doivent recevoir une priorité de remédiation plus élevée, surtout lorsque le système sous-jacent est Alpine ou une autre distribution basée sur musl.
À présent, il n’y a pas de IOC CVE-2026-123158 tels que les adresses IP d’attaquants confirmés, les domaines, les hachages de logiciels malveillants, ou l’infrastructure de commande et de contrôle. L’absence d’indicateurs statiques rend le suivi comportemental de l’authentification SSH et de l’activité de session subséquente particulièrement important.
Atténuation CVE-2026-123158
Le remède principal est l’installation d’OpenSSH 10.6p2 ou du package corrigé fourni par la distribution Linux. Les administrateurs Alpine doivent mettre à jour le système complet en utilisant les référentiels de paquets actuels et redémarrer sshd par la suite. Mettre à jour uniquement le package ne remplace pas le processus de démon SSH déjà en cours d’exécution.
Les organisations exploitant des conteneurs basés sur Alpine doivent reconstruire et redéployer toute image qui installe openssh-server. Mettre à jour simplement le système d’exploitation hôte ne corrige pas les paquets OpenSSH vulnérables intégrés dans les images de conteneurs.
Les administrateurs doivent également identifier l’exposition avant de supposer que chaque hôte Alpine est vulnérable. Les vérifications clés incluent :
- Déterminer si l’hôte utilise musl libc.
- Vérifier si sshd fonctionne avec PAM désactivé.
- Vérifier si l’authentification par mot de passe est activée.
- Identifier les comptes capables de se connecter dont le champ de mot de passe /etc/shadow est *.
- Examiner les privilèges attribués à ces comptes.
- Confirmer le package OpenSSH installé par rapport à la version corrigée du paquet de distribution.
Si un patch immédiat est impossible, les organisations doivent désactiver l’authentification par mot de passe SSH.
Configurer :
PasswordAuthentication no
et, le cas échéant :
KbdInteractiveAuthentication no
Les administrateurs doivent confirmer que l’authentification par clé publique fonctionne avant d’appliquer cette configuration pour éviter de perdre l’accès administratif légitime.
La configuration SSH doit alors être validée et le démon rechargé ou redémarré. Ensuite, une vérification externe doit confirmer que le serveur n’offre que l’authentification par clé publique.
Restreindre l’accessibilité réseau offre une défense supplémentaire en profondeur. SSH ne devrait généralement être accessible que depuis des réseaux administratifs de confiance, une infrastructure VPN, des hôtes bastions, ou des listes blanches explicites d’adresses IP sources plutôt que d’être universellement exposé à Internet.
Les organisations devraient également reconsidérer si SSH est nécessaire à l’intérieur des conteneurs. Les environnements d’orchestration modernes fournissent généralement des alternatives telles que docker exec ou kubectl exec, éliminant un service d’authentification inutilement accessible à distance.
Pour les systèmes potentiellement exposés, examinez les connexions historiques de mots de passe réussies survenues avant la remédiation. Portez une attention particulière aux comptes configurés sans mots de passe et aux identités normalement censées s’authentifier exclusivement avec des clés SSH.
Si une connexion réussie inattendue est identifiée, traitez le compte comme potentiellement compromis. Examinez l’historique shell disponible, l’exécution des processus, l’escalade de privilèges, les entrées authorized_keys nouvelles ou modifiées, les modifications des utilisateurs et des groupes, les tâches cron, les scripts de démarrage, l’installation de paquets, et les connexions réseau sortantes.
Les identifiants et les clés accessibles au compte compromis doivent être considérés comme potentiellement exposés et tournés selon les conclusions de l’enquête. Si le compte avait des privilèges administratifs, les défenseurs doivent étendre l’enquête à l’ensemble de l’hôte et à tous les systèmes accessibles en utilisant les identifiants stockés là.
Les matériaux de preuve de concept publics signifient que les organisations ne devraient pas attendre les preuves d’attaques généralisées avant d’appliquer la correction. Les prérequis d’exploitation réduisent la population vulnérable, mais les systèmes qui satisfont à ces conditions peuvent être accessibles à distance sans connaissance d’un mot de passe valide.
FAQ
Qu’est-ce que CVE-2026-123158 et comment fonctionne-t-il ?
CVE-2026-123158 est un contournement de l’authentification par mot de passe affectant OpenSSH sshd sur les systèmes Linux utilisant musl libc sans PAM. Lorsqu’un mot de passe excessivement long est passé à la fonction crypt() de musl, il peut renvoyer * en tant que valeur d’erreur. Si le compte cible a également * stocké dans /etc/shadow, les configurations sshd vulnérables peuvent incorrectement traiter les valeurs comme correspondant et permettre l’authentification.
Quand CVE-2026-123158 a-t-il été découvert pour la première fois ?
La vulnérabilité a été signalée par Özgün Kültekin de Wakefield. OpenSSH a publié le correctif de sécurité dans Portable OpenSSH 10.6p2 le 5 novembre 2026, et le CVE est devenu public le même jour. Les avis primaires examinés actuellement ne divulguent pas la date exacte de la découverte originale en privé par le chercheur.
Quel est l’impact de CVE-2026-123158 sur les systèmes ?
Une exploitation réussie permet à un attaquant distant non authentifié de se connecter à un compte qualifié sans connaître son mot de passe. L’impact résultant dépend des autorisations de ce compte. La compromission d’un compte de service ou standard peut exposer des données et des ressources applicatives, tandis que l’accès à un compte avec doas, sudo, ou des privilèges équivalents peut potentiellement mener à une compromission complète du système.
CVE-2026-123158 peut-il encore m’affecter en 2026 ?
Oui. Les installations OpenSSH vulnérables restent exposées jusqu’à ce que des correctifs soient appliqués ou que l’authentification par mot de passe soit désactivée. Les systèmes les plus à risque sont les environnements Linux basés sur musl tels qu’Alpine Linux exécutant sshd sans PAM et contenant des comptes sans mot de passe qualifiés. Du matériel de reproduction publique existe, bien qu’aucune exploitation confirmée dans la nature n’ait été signalée au 6 novembre 2026.
Comment puis-je me protéger de CVE-2026-123158 ?
Mettez à niveau vers OpenSSH 10.6p2 ou votre package corrigé de distribution et redémarrez sshd. Si le correctif ne peut pas être complété immédiatement, désactivez l’authentification par mot de passe et par clavier interactif, restreignez l’exposition SSH aux réseaux de confiance, et examinez les connexions par mot de passe réussies pour toute activité suspecte. Les administrateurs doivent continuer de surveiller les avis des fournisseurs pour des mises à jour des détails pour CVE-2026-123158 à mesure que l’intelligence sur l’exploitation évolue.
