SSHole : n'importe quel mot de passe ouvrait le serveur

Sur les systèmes musl sans PAM, un mot de passe de plus de 256 caractères suffisait pour entrer sur un compte sans mot de passe, parfois jusqu'à root. Le correctif est sorti le 5 novembre, et la première intrusion est arrivée dans la nuit.

Actualité du 7 novembre 2026 · 1 min 40 · 5 sources · 10 affirmations sourcées

En 30 secondes

Un compte sans mot de passe n'est pas protégé par ce vide : dans certaines configurations, il accepte n'importe quel mot de passe très long.
Installer le correctif ne suffit pas : sans redémarrage, l'ancien sshd continue d'accepter les connexions.
La faille n'a pas été trouvée par un serveur exposé, mais dans le code : le délai entre publication et attaque s'est compté en heures.

Les faits

Ce qui est établi, et ce qui ne l'est pas

Chaque affirmation de l'épisode, son statut et ses sources.

ÉtabliCVE-2026-123158 touche sshd dans OpenSSH avant 10.6p2, sous Linux avec la bibliothèque musl et sans PAM[3][1]
ÉtabliUn mot de passe de plus de 256 caractères est accepté sur un compte dont le champ mot de passe vaut une étoile, dès qu'un autre compte local possède un hachage SHA-256 ou SHA-512[1][3]
ÉtabliLa cause est dans musl : crypt() renvoie une étoile quand le hachage échoue, valeur identique à celle d'un compte sans mot de passe, et sshd compare les deux[1][4]
ÉtabliCorrigé dans OpenSSH 10.6p2, publié le 5 novembre 2026 ; il faut redémarrer sshd, le paquet seul ne remplace pas le service en cours[2][1]
ÉtabliAlpine a publié des paquets corrigés pour toutes les branches de 3.16 à edge, dont 3.21.10, 3.22.8, 3.23.8 et 3.24.4[1]
ÉtabliSont épargnés : les systèmes glibc, les configurations avec PAM actif, Dropbear, OpenBSD, les conteneurs sans sshd, les comptes verrouillés et les systèmes où l'authentification par mot de passe est désactivée[1][5]
RapportéSelon Previdian : première tentative moins de neuf heures après la publication du CVE, huit tentatives depuis une seule adresse géolocalisée au Japon, root obtenu sur un pot de miel sous Alpine[4]
InconnuNombre de serveurs exposés, outil utilisé et auteur de l'attaque non établis[4][5]
ÉtabliLe CVE a été publié le 5 novembre 2026 à 16 h 17 UTC, avec un score CVSS de 8.1[3]
RapportéLes comptes visés sont ceux sans mot de passe : root, les utilisateurs en clé seule et l'utilisateur alpine des images tiny-cloud, qui dispose de doas sans mot de passe[1][4]

Transcription

Le 5 novembre, à 16 h 17, heure UTC, la fiche de la faille OpenSSH est publiée. Moins de neuf heures plus tard, un attaquant obtenait root sur un serveur témoin, sans connaître aucun mot de passe.

CyberFlash, c'est l'émission cybersécurité de DecodeVox. Ici, on ne s'arrête pas aux gros titres : on décrypte les attaques, on révèle leurs mécanismes et on explique ce qu'elles changent concrètement.

Mais comment entrer sur un compte sans en connaître le mot de passe ?

Tout commence par une connexion SSH ordinaire, depuis Internet, sur le port 22. Pour un compte sans mot de passe, le serveur garde une étoile à la place du hachage. Il emprunte alors le sel d'un autre compte, et tente quand même de calculer le hachage. Avec un mot de passe de plus de 256 caractères, musl échoue et renvoie cette étoile : sshd compare deux fois la même valeur et laisse entrer.

Ce qui est établi : le correctif 10.6p2, publié le 5 novembre, et huit tentatives venues d'une seule adresse, au Japon. Ce qu'on ignore : combien de serveurs sont exposés, avec quel outil, et qui se cache derrière cette adresse.

Trois réflexes. D'abord, après la mise à jour, redémarrer sshd : le paquet ne remplace pas le service en cours. Ensuite, couper l'authentification par mot de passe partout où elle ne sert pas. Enfin, chercher dans les journaux une connexion acceptée par mot de passe sur un compte qui n'en a pas.

Le correctif est sorti le 5 novembre, et la première intrusion est arrivée dans la nuit qui a suivi. La fenêtre entre publication et attaque se compte désormais en heures.

Pour aller plus loin, retrouvez l'édition complète du jour sur notre plateforme en ligne, le lien en description. Abonnez-vous à DecodeVox pour ne rien manquer de nos prochains décryptages. Et dites-nous en commentaire : Chez vous, sshd a-t-il été redémarré ?

Les mots de l'épisode

sshd: Le service qui accepte les connexions SSH sur une machine : c'est lui qui vérifie le mot de passe ou la clé présentée.
musl: Une petite bibliothèque C utilisée par Alpine Linux et d'autres systèmes légers. C'est sa fonction de hachage qui renvoie une étoile en cas d'échec.
PAM: Le module standard qui gère l'authentification sur la plupart des distributions. Quand il est absent, sshd vérifie lui-même les mots de passe.
Hachage: Empreinte calculée à partir d'un mot de passe, stockée à sa place. Le serveur recalcule l'empreinte de la tentative et compare.

Sources