CVE-2026-123158 (SSHole) : un mot de passe long ouvre l’accès SSH à certains serveurs Alpine Linux

Ce que fait la faille

Alpine et quelques autres petites distributions Linux utilisent muslune bibliothèque C compacte qui fournit les fonctions de base dont les programmes ont besoin ; la plupart des grandes distributions utilisent glibc et compilent OpenSSH sans PAMun système Linux qui gère les connexions ; avec lui, sshd confie la vérification du mot de passe à un module séparé. Dans cette configuration, sshd vérifie lui-même le mot de passe : il calcule le hachage de ce que l’utilisateur a tapé et le compare au hachage enregistré pour le compte.

Les comptes sans mot de passe, comme root sur les images Alpine récentes ou les utilisateurs qui ne se connectent qu’avec une clé SSH, contiennent un simple * dans ce champ. Selon une analyse technique de la société de sécurité Ostorlab, musl renonce face aux mots de passe de plus de 256 octets et renvoie le texte * comme signal d’erreur. sshd compare alors ce * au * enregistré, constate qu’ils sont identiques et laisse entrer l’utilisateur. La fiche CVE décrit le même problème plus brièvement, comme une mauvaise interprétation de « si une chaîne est censée être un hachage de mot de passe ».

OpenSSH estime que la cause profonde se trouve « en dehors d’OpenSSH lui-même », mais qu’il peut bloquer le contournement dans sshd. Le correctif fait rejeter par sshd les hachages enregistrés de moins de quatre caractères, si bien qu’un * seul ne peut plus correspondre.

Qui est concerné

L’avis d’Alpine énumère quatre conditions qui doivent être réunies :

1. sshd fonctionne sans PAM : le paquet openssh-server, ou openssh-server-pam avec UsePAM no.
2. PasswordAuthentication vaut yes, la valeur par défaut d’OpenSSH.
3. La machine possède un compte dont le champ de mot de passe vaut *. Sous Alpine, cela inclut root (dans l’image de base depuis la version 3.16 environ), les utilisateurs à clé uniquement, les utilisateurs d’annuaires comme sssd ou winbind et l’utilisateur alpine des images tiny-cloud.
4. Au moins un compte local possède un vrai hachage de mot de passe de type $5$ ou $6$.

Se connecter directement en root exige aussi PermitRootLogin yes, mais Alpine prévient que doas peut offrir un autre chemin vers root. Les comptes verrouillés (! dans le champ de mot de passe) ne sont pas touchés, pas plus que les conteneurs Docker qui n’exécutent pas sshd.

Quelle gravité

La fiche CVE, rédigée par MITRE en tant que CNACVE Numbering Authority, organisme habilité à attribuer des identifiants CVE et à rédiger leur description officielle, attribue un score CVSS 3.1 de 8,1 (élevé), avec le vecteur AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H. OpenSSH qualifie le problème de critique. Alpine est plus direct : un attaquant qui atteint le port SSH a besoin d’une seule connexion et d’un mot de passe long, et cela « fonctionne à chaque fois » quand les conditions sont réunies.

Les attaques à ce jour

Du code de démonstration est apparu sur GitHub peu après la publication, et l’évaluation de la CISA dans la fiche CVE indique une preuve de concept publique. Au 8 novembre, la faille ne figure pas au catalogue des vulnérabilités exploitées de la CISA.

Deux entreprises qui exploitent des capteurs sur Internet ont publié ce qu’elles observent. GreyNoise a repéré la première tentative le 5 novembre à 18 h 34 UTC et dit avoir confirmé l’exploitation réussie de ses propres leurres, vulnérables à dessein, à partir du 7 novembre, avec 14 actions après connexion venant de quatre adresses. Previdian a compté 19 tentatives depuis 12 adresses dans 8 pays au 8 novembre, mais précise que ses données ne montrent pas si l’une d’elles a réussi. Aucune des deux n’a signalé d’organisation réelle touchée.

Le développeur d’OpenSSH Damien Miller a écrit que l’équipe n’avait appris le problème que la veille de la publication et qu’elle a agi vite parce que des agents d’IA redécouvrent désormais les failles publiées « en quelques heures ».

Que faire maintenant

1. Sous Alpine, lancez apk upgrade -U -a puis rc-service sshd restart. Alpine insiste : la mise à jour seule ne remplace pas le sshd déjà en cours d’exécution. Les versions 3.21.10, 3.22.8, 3.23.8 et 3.24.4 incluent déjà le correctif.
2. Sur les autres systèmes Linux compilés avec musl et sans PAM, passez à OpenSSH 10.6p2 ou au paquet corrigé de votre distribution.
3. Si vous ne pouvez pas encore mettre à jour, réglez PasswordAuthentication no. Vérifiez d’abord que la connexion par clé SSH fonctionne, gardez une session ouverte pendant la modification et contrôlez avec sshd -T | grep -i passwordauthentication. Notre guide pas à pas pour passer la connexion SSH aux clés explique comment le faire sans vous enfermer dehors.
4. Cherchez des traces d’intrusion. Alpine conseille de rechercher dans /var/log/messages les lignes « Accepted password for » sur des comptes sans mot de passe, comme root, alpine ou les utilisateurs à clé, et de vérifier l’usage de doas, les nouveaux utilisateurs et les fichiers authorized_keys. Si vous ne pouvez pas exclure une connexion, considérez la machine comme compromise.
5. Si vous construisez des images de conteneur qui exécutent sshd, reconstruisez-les à partir d’une base Alpine à jour et recréez les conteneurs.

C’est le deuxième contournement de connexion de la semaine : sur les pare-feu SonicWall, une faille du VPN permet aux attaquants de passer outre SAML et l’authentification multifacteur.