OpenSSH a publié la version 10.6p2 le 5 novembre pour corriger un contournement de l'authentification par mot de passe, CVE-2026-123158 (son découvreur l'appelle sshole ; CVSS 8,1). Le 9 novembre, l'agence américaine de cybersécurité et de sécurité des infrastructures (CISA) l'a ajoutée à son catalogue des vulnérabilités exploitées connues (Known Exploited Vulnerabilities, KEV), en invoquant des preuves d'exploitation active. La faille ne touche que les systèmes Linux qui utilisent la bibliothèque C musl sans PAM, Alpine étant le cas typique. La page de sécurité d'Ubuntu indique openssh comme « Not affected » sur toutes les versions et Debian classe son urgence au niveau « unimportant » : un VPS sous Ubuntu ou Debian ne demande donc aucune action pour cette faille. Ce qu'il faut vérifier, ce sont les systèmes Alpine, ainsi que tout sshd que vous auriez installé vous-même dans un conteneur Alpine. Pour la précédente série de changements d'OpenSSH, voir notre article d'octobre.

Les quatre conditions doivent être réunies

  • Vous utilisez le paquet openssh-server d'Alpine, qui est compilé sans PAM, ou bien openssh-server-pam avec UsePAM no.
  • PasswordAuthentication vaut yes. C'est la valeur par défaut d'OpenSSH : l'option est donc active, sauf si vous l'avez modifiée.
  • La machine possède un compte dont le champ de mot de passe est *, c'est-à-dire un compte sans mot de passe, censé ne se connecter que par clé. L'image de base d'Alpine livre root sous la forme root:* depuis la version 3.16 environ ; il en va de même pour l'utilisateur alpine des images officielles tiny-cloud, qui dispose en outre d'un doas sans mot de passe vers root. Root lui-même est protégé par le réglage par défaut PermitRootLogin prohibit-password, mais cela ne suffit pas si un autre compte peut devenir root.
  • Au moins un autre compte de la machine possède une véritable empreinte de mot de passe commençant par $5$ ou $6$. Lorsque les quatre conditions sont réunies, un attaquant qui connaît un nom de compte envoie un mot de passe très long, de 257 à 1024 octets (la NVD parle de 256 à 1024 caractères), et se retrouve connecté dès la première connexion. La cause : la fonction crypt() de musl renvoie * comme marqueur d'erreur lorsque le mot de passe dépasse 256 octets, et * est précisément ce qui est enregistré pour ces comptes, de sorte que sshd y voit une correspondance.

Ce qui n'est pas concerné

  • Les conteneurs qui n'exécutent pas sshd, soit la grande majorité des conteneurs Docker.
  • Les systèmes où PasswordAuthentication no est déjà défini ; les images cloud configurées par cloud-init écrivent cette ligne. Les systèmes qui utilisent openssh-server-pam avec UsePAM yes ne sont pas concernés non plus.
  • Le découvreur cite aussi OpenWrt, Buildroot et Yocto parmi les systèmes fondés sur musl. Ils ne sont concernés que si le sshd d'OpenSSH y est installé, et le correctif vient des mises à jour propres à chaque projet.

Comment corriger

  • Mettez à jour, puis redémarrez sshd : exécutez apk upgrade -U -a, puis rc-service sshd restart. La mise à jour du paquet ne redémarre pas un sshd en cours d'exécution. Alpine 3.21.10, 3.22.8, 3.23.8 et 3.24.4 contiennent le paquet corrigé ; les versions du paquet sont 10.3_p1-r2 sur 3.24, 10.2_p1-r1 sur 3.23, 10.0_p1-r11 sur 3.22, 9.9_p2-r1 sur 3.21 et 10.6_p2-r0 sur edge, des correctifs ayant aussi été publiés pour les branches plus anciennes, jusqu'à la 3.16.
  • Si vous ne pouvez pas encore mettre à jour, désactivez les connexions par mot de passe : définissez PasswordAuthentication no dans la configuration de sshd, redémarrez sshd, puis vérifiez avec sshd -T | grep -i passwordauthentication que la commande affiche no. Assurez-vous d'abord que votre connexion par clé fonctionne, et gardez votre session actuelle ouverte.
  • Si vous avez écrit un Dockerfile qui installe openssh-server dans une image Alpine, récupérez la nouvelle image de base, reconstruisez l'image et redémarrez le conteneur. Mettre à jour l'hôte n'y change rien.

Comment savoir si quelqu'un s'est connecté

Alpine conseille de chercher dans /var/log/messages les lignes de sshd contenant Accepted password for : une connexion par mot de passe réussie sur un compte qui n'a pas de mot de passe (alpine, root ou un utilisateur limité aux clés) signifie que la faille a été utilisée. Passez ensuite en revue l'usage de doas, les utilisateurs nouvellement créés et authorized_keys ; si vous ne pouvez pas exclure une connexion, considérez la machine comme compromise et suivez notre guide d'enquête et de re-sécurisation d'un VPS compromis. BleepingComputer a rapporté le 9 novembre que GreyNoise avait enregistré la première exploitation réussie le 7 novembre à 00:46 UTC, environ 40 heures après la publication du correctif ; une fois entrés, les attaquants ont mené une reconnaissance du système et des conteneurs, interrogé les services de métadonnées cloud, tenté de lire les empreintes de mots de passe et les clés SSH de root, et modifié authorized_keys pour conserver leur accès. Pour les bases des conteneurs, voir notre introduction à Docker ; quelle que soit la distribution, la connexion SSH par clé uniquement est le réglage qui épargne le plus d'ennuis, comme l'explique le pare-feu ufw et la connexion par clé SSH.