Ing. Calogero Bono
La vulnérabilité SSHole d'OpenSSH, suivie sous le nom CVE-2026-123158, est exploitée dans de vraies attaques. Selon BleepingComputer, les premières tentatives ont commencé le 5 novembre, le jour où un exploit de démonstration est apparu, et le lendemain a eu lieu le premier succès. Le bug permet d'entrer dans des comptes Linux sans connaître le mot de passe, dans certaines configurations. Si tu gères des serveurs Alpine Linux ou des conteneurs légers, la question te concerne directement.
Quelques termes, avant d'entrer dans les faits. OpenSSH est le logiciel qui permet de se connecter à distance aux serveurs. musl est une bibliothèque C alternative à celle la plus répandue, utilisée par exemple dans Alpine Linux. PAM est le système modulaire qui gère l'authentification sous Linux. Hash du mot de passe est la valeur sous laquelle le système conserve le mot de passe sous une forme illisible. C2 est le serveur de commande et contrôle grâce auquel les attaquants pilotent le malware.
Qu'est-ce que SSHole et comment fonctionne-t-elle ?
Selon BleepingComputer, la faille a été rendue publique par le chercheur Ozgun Kultekin. Elle concerne OpenSSH sur les systèmes Linux basés sur musl, dont Alpine, très utilisée dans les environnements cloud et virtuels.
Le mécanisme est le suivant. Certains comptes ont un astérisque dans le champ du mot de passe, pour empêcher la connexion par mot de passe. Si l'on envoie un mot de passe trop long, la fonction de hachage de musl renvoie un astérisque comme erreur. OpenSSH le prend pour une correspondance avec la valeur enregistrée et laisse entrer.
Nous en avions déjà parlé dans notre article sur le bug *sshole dans les comptes Alpine Linux.
Quels systèmes sont réellement exposés ?
The Hacker News indique un score CVSS de 8,1 et précise les conditions. Il faut Linux avec OpenSSH sur musl et PAM désactivé, ce qui inclut la configuration par défaut du serveur OpenSSH d'Alpine.
Kultekin explique qu'il faut des réglages d'authentification spécifiques et que les comptes avec un hash valide ne sont pas touchés. L'accès root est possible là où le compte compromis dispose de privilèges administratifs sans mot de passe.
Que font les attaquants ?
Selon GreyNoise, la première exploitation réussie remonte au 7 novembre à 00h46 UTC, environ 40 heures après le correctif. L'entreprise a enregistré 16 chaînes d'exploitation réussies contre des réseaux qu'elle protège, depuis six adresses IP. Elle précise toutefois qu'elles ne représentent pas l'activité globale.
Les attaquants ont effectué une reconnaissance du système et des conteneurs, interrogé les services de métadonnées cloud, tenté de lire les hash et les clés SSH de root et de modifier le fichier authorized_keys pour rester à l'intérieur. Previdian parle de 20 tentatives venant de 13 IP dans neuf pays. watchTower a observé des usages liés à des botnets et au cryptomining.
Qu'est-ce que TAC Agent ?
C'est un agent Python de commande et contrôle installé lors d'une attaque sur un système où l'attaquant a obtenu les privilèges root. Selon BleepingComputer, il exécute des commandes, effectue une reconnaissance approfondie, envoie et télécharge des fichiers et peut se mettre à jour. Il n'a pas de persistance intégrée, donc les attaquants configurent un service de démarrage.
Dans ce cas, il n'a pas réussi à atteindre le serveur C2 et n'a jamais reçu de tâches. Ars Technica, citant GreyNoise, attribue l'activité à un groupe appelé GT10 et note que la backdoor contient des commentaires en chinois et semble générée par l'IA. Le même groupe installe Python3 là où il manque.
Limites à connaître
Nous ne savons pas combien de systèmes ont été compromis. GreyNoise elle-même précise que ses 27,5 millions de scans sur le port 22 et ses 20,1 millions de sessions SSH ne sont pas des attaques SSHole confirmées. Les commentaires en chinois ne suffisent pas pour l'attribution, et les sources ne s'accordent pas sur l'auteur. Ars Technica parle d'un groupe nommé GT10, BleepingComputer ne le cite pas.
Ce qui change pour ceux qui travaillent avec le numérique
Si tu administres des serveurs Linux, mets à jour OpenSSH vers la version 10.6p2, publiée le 5 novembre. Sinon, désactive l'authentification par mot de passe via SSH, comme le conseille BleepingComputer. Vérifie ensuite les connexions par mot de passe réussies sur les comptes avec un astérisque dans /etc/shadow, les clés SSH non autorisées et les fichiers ou services de démarrage de TAC Agent. Ceux qui utilisent Alpine dans des conteneurs doivent reconstruire les images. Si tu as des serveurs gérés par un tiers, demande s'ils ont été mis à jour, par exemple avec un hébergement avec mises à jour de sécurité gérées.
Notre avis
Ce cas montre à quel point la confiance dans une valeur d'erreur est fragile. Un astérisque renvoyé par une bibliothèque devient une clé valide pour un autre composant. Ce n'est pas une faille exotique, c'est une erreur à la frontière entre deux composants. La donnée la plus utile est la rapidité. Le code d'attaque est apparu environ quatre heures après le correctif. La marge entre le patch et l'exploitation se mesure désormais en heures, et celui qui met à jour en fin de mois est déjà en retard.
Questions fréquentes
SSHole concerne-t-il tous les serveurs Linux ?
Non. Elle concerne OpenSSH sur les systèmes avec musl et PAM désactivé, comme la configuration par défaut d'Alpine. Il faut aussi des réglages d'authentification spécifiques.
Quelle est la version corrigée d'OpenSSH ?
La 10.6p2, publiée le 5 novembre selon BleepingComputer. La mise à jour est la mesure principale.
Si je ne peux pas mettre à jour tout de suite, que faire ?
Désactive l'authentification SSH par mot de passe, comme le suggère BleepingComputer. Contrôle ensuite les accès suspects.
Que recherchent les attaquants ?
Selon GreyNoise, les hash de mots de passe, les clés SSH de root et les métadonnées cloud. Ils tentent aussi de modifier authorized_keys pour rester à l'intérieur.
Comment reconnaître TAC Agent ?
Cherche ses fichiers et les services de démarrage créés pour lui. BleepingComputer conseille aussi de vérifier les clés SSH non autorisées.
Ce qu'il faut surveiller dans les prochaines semaines sur SSH et musl
Le tableau est encore en évolution, avec de nouvelles données attendues de la part de ceux qui suivent les attaques. Mieux vaut suivre quelques éléments concrets.
- Suis les mises à jour de GreyNoise et Previdian sur le nombre de systèmes compromis.
- Vérifie quand ta distribution publie les images Alpine avec OpenSSH corrigé.
- Revois quels comptes ont un astérisque dans /etc/shadow et s'ils sont encore nécessaires.
