Skip to content
Hacker Posts

OpenSSH sur Alpine : contournement d'authentification (CVE-2026-123158)

CVE-2026-123158 permet de se connecter à certains comptes OpenSSH avec n'importe quel mot de passe très long, sur musl sans PAM — la config par défaut d'Alpine. Correctif : OpenSSH 10.6p2.

Publié le 3 min de lecture
cveopensshalpinelinuxalerte

Une faille d'OpenSSH permet de se connecter à distance à un serveur Alpine Linux sans connaître le mot de passe : il suffit de saisir un mot de passe d'au moins 256 caractères. Selon le NVD, CVE-2026-123158 touche « sshd dans OpenSSH avant 10.6p2 sur Linux, quand la musl libc est utilisée sans PAM » — et cite Alpine Linux comme plateforme type. Score CVSS 8.1, complexité d'attaque élevée. Le correctif est OpenSSH 10.6p2, publié le 5 novembre.

Ce qui est touché

  • Les hôtes Linux sous OpenSSH antérieur à 10.6p2 avec musl libc et PAM désactivé. C'est le cas de la configuration sshd par défaut d'Alpine.
  • Non concernés : les distributions sous glibc, les systèmes qui authentifient via PAM, Dropbear, et les systèmes non-Linux.

Alpine a corrigé dans les versions 3.21.10, 3.22.8, 3.23.8 et 3.24.4, avec des rétroportages pour les branches plus anciennes. D'après Next.ink, les images Alpine pour le cloud sont vulnérables de la 3.18.11 à la 3.24.3. Le paquet openssh corrigé est 10.3_p1-r2.

Le mécanisme

Pour un compte sans mot de passe, le système enregistre un astérisque (*) à la place de l'empreinte. La bibliothèque musl refuse de calculer l'empreinte d'un mot de passe de plus de 256 caractères et renvoie, elle aussi, *. OpenSSH — via un chemin de code hérité du correctif 2016 contre l'énumération de comptes (CVE-2016-6210) — compare les deux *, les trouve identiques et ouvre la session.

Trois conditions doivent être réunies : l'authentification SSH par mot de passe est activée (le défaut), au moins un compte n'a pas de mot de passe (sur Alpine, root est livré sans mot de passe) et au moins un autre compte en possède un. Un mot de passe d'environ 256 à 1024 caractères déclenche la faille. Les comptes dotés d'une vraie empreinte ne sont pas contournés. Damien Miller, de l'équipe OpenSSH, la qualifie de critique.

État de l'exploitation

L'article de Next.ink ne fait pas état d'exploitation. Les rapports en langue anglaise (The Hacker News, citant l'opérateur de honeypot Previdian) décrivent en revanche des tentatives moins de neuf heures après la publication de la CVE, avec obtention de root sur un honeypot Alpine. À considérer comme un signalement isolé, mais la fenêtre entre divulgation et sondage est manifestement courte.

Que faire

  1. Mettre à jour vers OpenSSH 10.6p2 (ou le paquet corrigé de votre distribution), puis redémarrer sshd.
  2. Sur Alpine : apk upgrade openssh vers au moins 10.3_p1-r2, puis redémarrer le service.
  3. Corriger les instances cloud déjà démarrées à partir d'images Alpine anciennes — rebâtir l'image ne suffit pas pour ce qui tourne déjà.
  4. Si le correctif ne peut être appliqué tout de suite, désactiver l'authentification par mot de passe (PasswordAuthentication no) — après avoir vérifié que la connexion par clé fonctionne.
  5. Auditer authorized_keys, les comptes récemment créés et l'usage de doas sur les hôtes exposés.

Ce que les autres n'ont pas relevé

L'avis CERTFR-2026-AVI-1480 décrit bien cette faille d'Alpine, mais référence l'identifiant CVE-2026-119977. Or, dans la base NVD, cet identifiant correspond à une tout autre vulnérabilité : une exécution de code à distance dans le cœur de WordPress. L'identifiant de cette faille OpenSSH est CVE-2026-123158, confirmé par le NVD, la base de sécurité d'Alpine et le portage éditorial de Next.ink. Vérifiez vos tableaux de suivi : indexée sous le mauvais numéro, cette correction risque d'être rapprochée du mauvais produit.

Articles liés