Des experts en cybersécurité signalent une exploitation active de la faille *SSHole permettant aux pirates d'accéder à des appareils Linux via SSH,

Les attaquants déploient des portes dérobées

La faille de sécurité *SSHole fait actuellement l'objet d'une exploitation active par des pirates informatiques. Cette vulnérabilité affecte les systèmes Linux utilisant conjointement OpenSSH et la bibliothèque de code musl, permettant d'accéder sans authentification à des comptes privilégiés en quelques secondes. Des groupes malveillants mèneraient déjà des « intrusions sophistiquées » et déploient des portes dérobées pour cibler divers réseaux. Bien que des conditions techniques spécifiques soient requises pour que l'attaque fonctionne correctement, la menace pèse lourdement sur plusieurs machines, notamment celles fonctionnant sous Alpine Linux.

OpenSSH est touché par une faille permettant de contourner l’authentification. Elle affecte les systèmes Alpine Linux exécutant le paquet standard openssh-server. Les attaquants disposant d’un accès au réseau, d’un identifiant valide et d’un mot de passe compris entre 257 et 1 024 octets peuvent se connecter à des comptes configurés sans mot de passe, y compris les comptes utilisant uniquement une clé et, sous certaines conditions, le compte root.

Référencée sous l'identifiant CVE-2026-123158, la faille *SSHole provient d’une interaction entre le mécanisme d’emprunt de sel d’OpenSSH (introduit en 2016 pour empêcher l’énumération des noms d’utilisateur) et le comportement de la bibliothèque musl libc, qui renvoie un astérisque nu lorsque la fonction crypt() reçoit un mot de passe dépassant 256 octets, ce qui correspond par méprise à l’astérisque stocké d’un compte sans mot de passe.

Bien que cette combinaison de paramètres paraisse complexe, la menace est jugée très sérieuse, car elle touche un grand nombre d'équipements, notamment ceux qui fonctionnent sous Alpine Linux, très utilisée pour les images de conteneurs Docker dans le cloud. De plus, la simplicité d'exécution permet de tester et d'identifier rapidement les serveurs SSH exposés sur Internet. Pour les responsables informatiques, il s'agit d'un signal d’alarme.

OpenSSH a publié la version 10.6p2 et Alpine a mis à disposition des paquets corrigés dans la journée suivant la découverte de la faille ; aucune exploitation n’avait été signalée au moment de la divulgation. Cependant, un nouveau rapport alerte sur une exploitation active par des pirates informatiques.

Attaques en cours observés par les experts en cybersécurité

Plusieurs entreprises de cybersécurité ont confirmé l'existence de campagnes d'attaque réelles. La société de cybersécurité Greynoise a signalé que ses systèmes-pièges situés en Asie du Sud-Est subissent des assauts menés par un groupe identifié sous le nom GT10, lequel réalise des intrusions matures. Les chercheurs de Greynoise ont réussi à accéder à un serveur de ce groupe, révélant l'usage d'une porte dérobée nommée « TAC Agent ».


Selon le rapport des chercheurs, cette porte dérobée est conçue pour exécuter des commandes système, faire de la reconnaissance et maintenir un accès persistant au système. Ce logiciel malveillant contient des commentaires en langue chinoise et semble avoir été généré à l'aide d'outils d'IA. Le groupe GT10 installe aussi le paquet Python3 sur les machines cibles lorsque celui-ci est absent, afin d'assurer le fonctionnement de leur outil.

En parallèle, la société watchTowr a observé une activité d'exploitation liée à des réseaux de robots et au minage de cryptomonnaies, tandis que Previdian a recensé 20 tentatives provenant de 13 adresses IP distinctes réparties dans 9 pays. Il est vivement conseillé aux administrateurs utilisant OpenSSH d'installer immédiatement la mise à jour de sécurité et d'examiner attentivement leurs configurations actuelles s'ils utilisent la bibliothèque musl.

Cet incident souligne à quel point la combinaison de choix de conception entre des composants open source indépendants peut créer des failles de sécurité critiques des années plus tard. Alpine Linux étant très répandue dans les images de base de conteneurs et les environnements cloud natifs, l’ampleur des répercussions pour les systèmes non corrigés est considérable, en particulier lorsque l’authentification par mot de passe reste activée par défaut.

L’impact sur les infrastructures informatiques vulnérables

Si votre organisation utilise des équipements sous Linux (comme des pare-feu réseau, des baies de stockage ou des capteurs IoT propriétaires), vous êtes potentiellement exposé à ce risque. Selon les experts, l’impact d’une compromission de type *SSHole est grave. Une fois qu’un attaquant a obtenu un Shell interactif, il peut se déplacer latéralement au sein du réseau interne, exfiltrer des données sensibles ou déployer un rançongiciel.


Pour les entreprises, les experts en cybersécurité insistent sur le fait que cette vulnérabilité critique représente un risque spécifique en matière de souveraineté des données et de conformité. Pour protéger votre organisation, les administrateurs peuvent mettre en œuvre les mesures suivantes :

• auditer les configurations SSH : analysez immédiatement tous les serveurs Linux à la recherche de clés publiques situées dans /root/.ssh/authorized_keys qui ne devraient pas s’y trouver. Supprimez immédiatement toute clé générique ou de provisionnement ;
• mettre en place une rotation des clés : assurez-vous que les clés SSH sont renouvelées périodiquement. Si vous utilisez un déploiement automatisé, passez à un modèle d’accès « Just-In-Time » (JIT) plutôt qu’à des clés statiques ;
• désactiver l’authentification par mot de passe : configurez le fichier /etc/ssh/sshd_config pour définir explicitement PasswordAuthentication no et PermitRootLogin no. N’utilisez que l’authentification basée sur l’identité avec des périmètres d’accès restreints ;
• utiliser l’authentification multifactorielle (MFA) pour SSH : dans la mesure du possible, intégrez SSH à l’authentification multifactorielle (MFA) via PAM (Pluggable Authentication Modules). Cela ajoute une couche de friction essentielle que le simple vol de clé ne peut contourner ;
• mettre en place une surveillance : utilisez une journalisation centralisée (SIEM) pour être alerté en cas de connexions SSH réussies, en particulier celles provenant de l’extérieur de vos sous-réseaux de gestion attendus.

Outre les mesures de précaution contre la menace, les organisations doivent également vérifier si cette faille a déjà été exploitée contre leurs serveurs. La présence d’une entrée « Accepted password » dans le fichier /var/log/messages pour un compte ne disposant pas de mot de passe, tel que root, un utilisateur utilisant uniquement une clé ou l’utilisateur par défaut « alpine », constitue un signe fort de compromission par *SSHole.

Alpine recommande de vérifier l’utilisation de doas, les utilisateurs et fichiers récemment créés sur les machines exposées, et précise dans son avis que tout serveur pour lequel une connexion ne peut être exclue doit être considéré comme compromis. Ozgun Kultekin, le chercheur de Wakefield qui a découvert la vulnérabilité, a également publié sur GitHub un script de vérification qui identifie les serveurs exposés et répertorie les comptes à risque.

Sources : Greynoise, watchTowr, Previdian

Et vous ?

Quel est votre avis sur le sujet ?
Que pensez-vous de la faille de sécurité *SSHole et des risques pour les infrastructures informatiques ?

Voir aussi

Une faille dans OpenSSH permet aux pirates de se connecter à des comptes Linux dont le mot de passe est désactivé, simplement en saisissant un mot de passe de plus de 256 octets

Une faille de sécurité "critique" a été découverte dans OpenSSH, elle affecte la quasi-totalité des systèmes Linux et 14 millions de serveurs connectés à internet sont vulnérables, d'après Qualys

Un chercheur en sécurité rapporte avoir détecté une exploitation réussie de la faille PHP2Shell, alors que des millions d'hôtes PHP tardent à appliquer les correctifs et restent exposés en ligne