Alpine Linux OpenSSH : contournement de l'authentification par mot de passe dans sshd sans PAM (CVE-2026-123158)

Ce qui s'est passé

Alpine Linux a publié un avis de sécurité pour son serveur OpenSSH le 2026-11-05. Il décrit un contournement de l'authentification par mot de passe. Une personne pouvant atteindre le port SSH peut se connecter aux comptes qui n'ont pas de mot de passe défini. Elle n'a besoin de connaître aucun mot de passe, et une seule connexion suffit. Aucun identifiant CVE n'avait été attribué au moment de la publication de l'avis par Alpine. Le problème est désormais suivi sous le nom CVE-2026-123158.

Le 2026-11-09, la CISA a ajouté la CVE-2026-123158 à son catalogue des vulnérabilités connues comme exploitées. La CISA ne donne aucun détail sur les attaques.

Selon Alpine, la cause réside dans la manière dont sshd vérifie les mots de passe lorsqu'il est compilé sans PAM. Il calcule l'empreinte de la tentative de mot de passe avec la fonction de la bibliothèque C crypt() et compare le résultat au champ de mot de passe stocké. Pour les comptes sans mot de passe, sshd emprunte le sel d'un autre compte. musl, la bibliothèque C utilisée par Alpine, renvoie la chaîne * depuis crypt() comme erreur lorsque le mot de passe dépasse 256 octets. * est aussi la valeur stockée dans le champ de chaque compte sans mot de passe ; la comparaison réussit donc et la connexion aboutit. Les développeurs d'OpenSSH ont modifié sshd pour éviter ce cas (commit 4353fdc, dans OpenSSH 10.6p2). Ils décrivent ce contournement comme touchant « certaines configurations et certaines configurations d'exécution ».

Qui est concerné

Le problème ne touche pas OpenSSH sous Linux de manière générale. L'avis d'Alpine indique que vous n'êtes concerné que si toutes les conditions suivantes sont réunies :

• Vous exécutez sshd sur Alpine Linux avec le paquet openssh-server, compilé sans PAM. Ou vous exécutez openssh-server-pam avec UsePAM no.
• PasswordAuthentication vaut yes. C'est la valeur par défaut d'OpenSSH.
• Le système comporte un compte dont le champ de mot de passe dans /etc/shadow vaut *. Cela inclut :
  • root, livré avec root:* depuis environ Alpine 3.16. root ne peut être atteint directement que si PermitRootLogin yes est défini. Cependant, tout autre compte accessible qui peut devenir root, par exemple via doas, suffit.
  • Les utilisateurs n'utilisant que des clés, créés avec adduser sans mot de passe, ou avec usermod -p '*'.
  • Les utilisateurs d'annuaires passant par musl-nscd (nslcd, winbind, sssd).
  • L'utilisateur alpine des images officielles tiny-cloud.
• Au moins un compte local possède un hachage de mot de passe $5$ ou $6$.

Alpine indique que les versions concernées sont 3.21 à 3.24, edge, ainsi que les versions plus anciennes 3.16 à 3.20.

Images tiny-cloud : les images officielles tiny-cloud de la version 3.18.11 à 3.24.3 contiennent un utilisateur alpine dont le champ de mot de passe vaut *, ainsi qu'un doas sans mot de passe. Elles deviennent exploitables dès qu'un hachage $6$ existe sur la machine. Cela se produit, par exemple, lorsqu'un administrateur définit un mot de passe pour la console ou lorsque les données utilisateur ajoutent un utilisateur avec hashed_passwd. Un attaquant peut alors se connecter en tant qu'alpine et devenir root.

Non concerné :

• Debian, Ubuntu, RHEL et les autres distributions basées sur glibc, dont sshd utilise PAM. Le comportement défectueux de crypt() provient de musl.
• Docker et les autres conteneurs n'exécutant pas sshd.
• Les systèmes avec PasswordAuthentication no.
• Les systèmes utilisant openssh-server-pam avec UsePAM yes.
• Les comptes verrouillés dont le champ de mot de passe commence par !.
• Les systèmes où aucun compte ne possède de hachage de mot de passe de type $.
• Les images cloud configurées avec cloud-init, qui définit PasswordAuthentication no.

Que faire maintenant

1. Mettez à jour openssh sur chaque système Alpine qui exécute sshd : apk upgrade -U -a. Le paquet corrigé est inclus dans Alpine 3.21.10, 3.22.8, 3.23.8 et 3.24.4. Les versions corrigées du paquet openssh sont :

   • edge : 10.6_p2-r0
   • 3.24 : 10.3_p1-r2
   • 3.23 : 10.2_p1-r1
   • 3.22 : 10.0_p1-r11
   • 3.21 : 9.9_p2-r1
   • 3.20 : 9.7_p1-r6
   • 3.19 : 9.6_p1-r3
   • 3.18 : 9.3_p2-r4
   • 3.17 : 9.1_p1-r7
   • 3.16 : 9.0_p1-r6

   La version 3.21 a atteint sa fin de support le 2026-11-01. Alpine a tout de même publié des paquets corrigés pour toutes les versions remontant à 3.16.

2. Redémarrez sshd : rc-service sshd restart. La mise à jour du paquet ne redémarre pas le démon en cours d'exécution. Sans redémarrage, le système reste vulnérable.

3. Si vous ne pouvez pas mettre à jour immédiatement, désactivez les connexions par mot de passe. Vérifiez d'abord que la connexion par clé SSH fonctionne, et gardez votre session actuelle ouverte jusqu'à ce qu'une nouvelle connexion ait réussi. Définissez ensuite PasswordAuthentication no, y compris à l'intérieur des blocs Match éventuels. Vérifiez la configuration avec sshd -t, redémarrez avec rc-service sshd restart, puis confirmez le réglage avec sshd -T | grep -i passwordauthentication. L'avis d'Alpine indiqué ci-dessous fournit des commandes prêtes à l'emploi pour cela. La mise à jour ou la désactivation des connexions par mot de passe suffit à fermer la faille.

4. Mettez à jour toutes les instances en cours d'exécution issues d'images tiny-cloud antérieures à 3.21.10, 3.22.8, 3.23.8 et 3.24.4, ou désactivez l'authentification par mot de passe sur celles-ci. Ces images ne contiennent pas le paquet corrigé.

5. Si vous compilez vous-même OpenSSH sur un système basé sur musl sans PAM, passez à OpenSSH 10.6p2.

6. Recherchez sur les systèmes exposés des signes d'intrusion, comme décrit ci-dessous.

Comment vérifier si vous êtes concerné

• Vérifiez la distribution : cat /etc/alpine-release. Si le fichier n'existe pas, le système n'est pas Alpine et cet avis ne s'applique pas.
• Vérifiez le paquet installé : apk info -v | grep openssh. Comparez la version avec la liste ci-dessus.
• Vérifiez les réglages actifs de sshd : sshd -T | grep -i -E 'usepam|passwordauthentication'. Vous n'êtes pas concerné par ce problème si passwordauthentication no est affiché, ou si vous utilisez openssh-server-pam et que usepam yes est affiché.
• Recherchez les comptes sans mot de passe : grep -E '^[^:]+:\*:' /etc/shadow.
• Recherchez les comptes avec un hachage $5$ ou $6$ : grep -E '^[^:]+:\$[56]\$' /etc/shadow.

Si les deux recherches renvoient des résultats, que l'authentification par mot de passe est activée et que le paquet n'est pas encore corrigé, le système est vulnérable.

Signes d'intrusion : recherchez dans /var/log/messages les lignes sshd Accepted password for concernant un compte sans mot de passe, comme alpine, root ou tout utilisateur n'utilisant que des clés. Examinez aussi l'utilisation de doas, les utilisateurs créés récemment, les fichiers modifiés récemment et les fichiers authorized_keys sur les machines exposées. Le conseil d'Alpine : si vous ne pouvez pas exclure une telle connexion, considérez la machine comme compromise.

Sources

• https://nvd.nist.gov/vuln/detail/CVE-2026-123158
• https://www.cisa.gov/known-exploited-vulnerabilities-catalog