Discussion :

[Eliora]

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 vulnérabilité critique affectant les serveurs OpenSSH sur les systèmes Linux compilés avec la bibliothèque C « musl » au lieu de « glibc » permet à des attaquants distants de contourner facilement l'authentification et d'accéder à des comptes sur lesquels l'authentification par mot de passe devrait être désactivée. Ce bug, surnommé *SSHole et référencé sous le numéro CVE-2026-123158, a été découvert par Ozgun Kultekin, chercheur chez Wakefield, et existe depuis dix ans. Il touche la distribution Linux légère Alpine, largement utilisée pour les images de conteneurs Docker dans le cloud. « Sur les systèmes concernés, l'exploit est d'une simplicité déconcertante : il suffit d'envoyer un mot de passe comportant entre 257 et 1 024 caractères », a déclaré Jake Knott, de watchTowr. Les responsables d'OpenSSH ont réagi rapidement en ajoutant une mesure d'atténuation dans la mise à jour d'urgence OpenSSH 10.6p2.

OpenSSH (également connu sous le nom d'OpenBSD Secure Shell) est une suite d'utilitaires réseau sécurisés basée sur le protocole Secure Shell (SSH), qui fournit un canal sécurisé sur un réseau non sécurisé dans une architecture client-serveur. OpenSSH a vu le jour sous la forme d'un fork du programme libre SSH développé par Tatu Ylönen ; les versions ultérieures du SSH de Ylönen étaient des logiciels propriétaires proposés par SSH Communications Security. OpenSSH a été publié pour la première fois en 1999 et est actuellement développé dans le cadre du système d'exploitation OpenBSD.

Une vulnérabilité critique affectant les serveurs OpenSSH sur les systèmes Linux compilés avec la bibliothèque C « musl » au lieu de « glibc » permet à des attaquants distants de contourner facilement l’authentification et d’accéder à des comptes sur lesquels l’authentification par mot de passe devrait être désactivée. Cette faille touche la distribution Linux légère Alpine, largement utilisée pour les images de conteneurs Docker dans le cloud, ainsi que les distributions Linux destinées aux systèmes embarqués.

Ce bug de sécurité, surnommé *SSHole et référencé sous le numéro CVE-2026-123158, a été découvert par Ozgun Kultekin, chercheur au sein de la société de tests de sécurité Wakefield, et existe depuis dix ans. Les responsables d’OpenSSH ont réagi rapidement en ajoutant une mesure d’atténuation pour cette faille dans la mise à jour d’urgence OpenSSH 10.6p2 publiée récemment, même s’ils affirment que le bug ne se trouve pas réellement dans leur code.

« Ce n’est pas tous les jours que l’« exploit » d’une vulnérabilité dans une technologie aussi répandue qu’OpenSSH consiste simplement à « envoyer un mot de passe long » ou à « envoyer beaucoup de caractères A », mais c’est pourtant le cas », a déclaré Jake Knott, responsable du renseignement sur les menaces chez watchTowr, une société spécialisée dans la gestion préventive des expositions. « Sur les systèmes concernés, l’exploit est d’une simplicité déconcertante : il suffit d’envoyer un mot de passe comportant entre 257 et 1 024 caractères. »

Heureusement, cette faille ne peut fonctionner que si certaines conditions sont réunies :

• La distribution Linux doit utiliser musl, ce qui signifie que de nombreuses distributions serveur courantes, telles que Debian, Ubuntu et Fedora, ne sont pas concernées
  
• Le système doit utiliser OpenSSH et non d’autres implémentations de serveur SSH telles que Dropbear, que de nombreuses distributions embarquées utilisent
  
• OpenSSH doit être configuré sans prise en charge des modules d’authentification enfichables (PAM), le framework de connexion Linux le plus courant
  
• OpenSSH doit autoriser l’authentification par mot de passe
  
• L’attaquant doit connaître le nom d’un compte pour lequel la connexion par mot de passe a été désactivée au niveau du système

Ces conditions sont remplies dans la configuration par défaut d’Alpine Linux et de son nom d’utilisateur intégré « alpine », ce qui permet d’exécuter des commandes en tant que root. Le projet Alpine a publié des mises à jour d’urgence pour le paquet openssh et recommande aux utilisateurs qui ne peuvent pas effectuer la mise à jour de désactiver l’authentification par mot de passe dans la configuration d’OpenSSH et de configurer l’authentification par clé.

Pourquoi cette attaque basique parvient-elle à fonctionner ?

Cette faille résulte de trois modifications apportées à plusieurs années d’intervalle, chacune visant à résoudre un problème différent. En 2012, les développeurs de musl ont limité la longueur des mots de passe à 256 octets afin d’empêcher les attaquants de monopoliser les ressources du serveur en envoyant de longs mots de passe devant être hachés dans le cadre du processus de vérification de connexion.

Parallèlement, ils ont également fait en sorte que la fonction de hachage des mots de passe de la bibliothèque renvoie un astérisque (*) en cas d’échec. Cet astérisque est le même caractère qu’Unix utilise depuis les années 1980 pour marquer les comptes pour lesquels aucun mot de passe ne doit jamais correspondre — c’est-à-dire les comptes dont le mot de passe est désactivé au niveau du système.

En 2016, OpenSSH a modifié la manière dont il vérifie les mots de passe pour les comptes dont le champ de mot de passe ne fournit pas de sel pour le hachage, en empruntant le sel d’un autre compte afin d’empêcher les attaquants de deviner les noms d’utilisateur existants par des tentatives de connexion par force brute et en chronométrant les réponses du serveur. Puis, en 2022, Alpine a remplacé le champ de mot de passe de l’utilisateur root par un astérisque afin que les connexions par clé SSH continuent de fonctionner pour ce compte.

Lorsqu’un attaquant envoie un mot de passe trop long pour un compte dont le mot de passe est désactivé sur un tel système, la tentative de hachage échoue et renvoie un astérisque, que sshd compare à l’astérisque stocké dans le champ « mot de passe » du compte. Les deux correspondent, et la connexion aboutit.

Les images cloud d’Alpine Linux constitueront la cible principale

Le paquet OpenSSH standard d’Alpine est compilé sans PAM, et les connexions par mot de passe sont activées par défaut ; les serveurs Alpine remplissent donc les conditions dès leur installation. Sur les images cloud officielles publiées entre les versions 3.18.11 et 3.24.3, le compte utilisateur par défaut, nommé « alpine », fait partie des comptes dont le mot de passe est désactivé, et les images lui accordent des privilèges « doas » sans mot de passe.

Par conséquent, un attaquant qui se connecte en tant que cet utilisateur peut ensuite passer au compte root ; les images sont donc exposées dès qu’un administrateur définit un mot de passe pour n’importe quel autre compte du système, car l’existence d’un compte légitime doté d’un vrai mot de passe est nécessaire pour que cette attaque fonctionne. Contrairement à la faille critique « regreSSHion » de 2024, celle-ci se limite à l’environnement musl, mais ne nécessite aucune ingénierie d’exploitation particulière.

« Les serveurs SSH exposés à Internet sont déjà soumis 24 heures sur 24 à des tentatives de deviner les mots de passe et à des attaques par force brute », a déclaré Knott. « Exploiter cette vulnérabilité signifie simplement que ces mêmes attaquants ajoutent une tentative de mot de passe très long à cette liste d’attaques par force brute. Nous serions extrêmement surpris de ne pas voir des attaquants utilisant des outils de force brute SSH tenter cette attaque d’ici le week-end. »

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. 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. Kultekin a également publié sur GitHub un script de vérification qui identifie les serveurs exposés et répertorie les comptes à risque.

En juin 2026, des chercheurs en sécurité publièrent un exploit détaillé et fonctionnel pour une faille de type « use-after-free » du noyau Linux qui permettait à un utilisateur local non privilégié d'élever ses privilèges au niveau root et de s'échapper d'un conteneur. La faille, CVE-2026-23111, se trouvait dans le code de filtrage de paquets nf_tables du noyau et avait été corrigée en amont le 5 février 2026.

Sources : *sshole ; NIST (NVD)

Et vous ?

Pensez-vous que cette information est crédible ou pertinente ?
Quel est votre avis sur le sujet ?

Voir aussi :

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

La suite d'utilitaires réseau sécurisés OpenSSH 10.4 est disponible, avec la prise en charge des signatures post-quantiques composites et des corrections de plusieurs failles de sécurité

Une faille d'exécution de code dans le firmware UEFI menace la plupart des fournisseurs de serveurs et des centres de données à l'échelle mondiale, la vulnérabilité a un niveau de gravité de 9,5 sur 10

[Fagus]

la fonction de hachage des mots de passe de la bibliothèque renvoie un astérisque (*) en cas d’échec
en 2022, Alpine a remplacé le champ de mot de passe de l’utilisateur root par un astérisque

C'est de l'héritage, mais je trouve ça fou d'utiliser un code d'erreur de retour en c, pour quelque chose d'aussi important, alors que pour un bool de plus on peut renvoyer une structure qui contient le code d'erreur genre :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
struct resultat {
    bool succes;
    union {
        int valeur_retour;
        int code_erreur;
    };
};

[Freem]

C'est de l'héritage, mais je trouve ça fou d'utiliser un code d'erreur de retour en c, pour quelque chose d'aussi important, alors que pour un bool de plus on peut renvoyer une structure qui contient le code d'erreur genre :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
struct resultat {
    bool succes;
    union {
        int valeur_retour;
        int code_erreur;
    };
};

Ta structure, la, elle pèse entre 4 octets et 8 octects, en fonction de la taille de "int" sur ton compilateur local. En général sur un système moderne, ça sera 8 parce que sur gcc/clang/msvc, un int, c'est 4 octets, mais la norme dis "au moins deux".

"Pour un bool de plus" non. Ici la fonction crypt() retourne un pointeur, donc ton code marche pas. Si tu avais utilisé un type sur 8 octets (taille d'un pointeur sur une machine 64b) tu aurais une struct de 16 octets, parce que padding. C'est pas vraiment un overhead acceptable, surtout quand on peut juste retourner NULL.

La solution ici de toute façon est juste de ne pas modifier le comportement d'une fonction de sécurité en faveur de gens qui ne sont pas capable de tester qu'un pointeur est nul avant de s'en servir, ce qui est quand même un truc idiomatique, de retourner un pointeur nul pour un truc qui peux échouer. Genre, on ouvre un fichier? Ben on teste que l'ouverture à marché en vérifiant que le FILE* est pas nul. Je vois pas ce qu'il y a de sorcier...

[Fagus]

Ta structure, la, elle pèse entre 4 octets et 8 octects,...

Oui pardon, j'ai pas du tout cherché l'optimisation et j'ai juste écrit int comme concept général alors que j'aurais dû écrire en pseudo-code type_adapté.

Je peux imaginer que la fonction de hash sert à autre chose qu'ouvrir les sessions admin.

Mais ce que je voulais dire, c'est qu'utiliser un code magique d'erreur ("*") sur une fonction de validation de mot de passe, code magique qui peut-être interprété différemment selon qu'on compile avec la librairie a ou b, c'est plus risqué qu'utiliser une gestion d'erreur explicite.

Je sais que ce n'est pas idiomatique de faire ça en c par rapport à un code d'erreur, et que c'est de la programmation défensive de se dire qu'un jour quelqu'un ne se rendra pas compte que le code d'erreur est mal testé, mais la preuve, c'est que c'est arrivé. Car à des années d'intervalles et sur des librairies différentes, plus personne n'avait gardé le souvenir qu'implicitement le code d'erreur devait être correctement géré par la librairie, et que si on en écrit une autre, elle devrait suivre la convention implicite de la 1ère. Encore une fois, je dis ça en ayant juste lu l'article.

Ensuite, c'est des habitudes. Je programme maintenant en python, qui a un système dédié pour les erreurs . Alors qu'en c... autant pour un pointeur, tester qu'il n'est pas nul juste après fopen ou malloc je trouve ça clair. Autant les variable globales à la errno c'est ok en mono thread, autant utiliser un code spécial sur un test qui n'est pas sensé être intensif en calcul, mais sécurisé, je suis dubitatif.

[Mathis Lucas]

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