En bref

  • CVE-2026-123158 « sshole » : contournement total de l’authentification SSH sur Alpine Linux et systèmes musl libc sans PAM
  • Systèmes affectés : OpenSSH < 10.6p2 sur Alpine Linux, OpenWrt, Buildroot, Yocto
  • Exploité en moins de 9h après divulgation : mettre à jour et redémarrer sshd immédiatement

Les faits

Le 5 novembre 2026, l’équipe OpenSSH a publié la version 10.6p2 en réponse à une vulnérabilité critique dans le démon sshd : CVE-2026-123158, rapidement surnommée « sshole » par la communauté de sécurité. La faille permet à un attaquant distant de contourner entièrement l’authentification par mot de passe SSH sur les systèmes Linux compilés avec la bibliothèque C musl libc sans support PAM. Alpine Linux, l’une des distributions les plus utilisées dans les conteneurs Docker, Kubernetes et les environnements CI/CD, entre parfaitement dans ce profil.

Le mécanisme d’exploitation repose sur un comportement spécifique de musl libc. Lorsque le daemon sshd reçoit un mot de passe d’une longueur supérieure à 256 caractères, la fonction musl crypt() — chargée de hacher le mot de passe pour le comparer au hash stocké dans /etc/shadow — retourne la chaîne « * » au lieu du hash calculé. Or, les comptes sans mot de passe configuré dans /etc/shadow contiennent précisément « * » comme marqueur de compte verrouillé. sshd interprète alors l’égalité entre les deux « * » comme une authentification réussie.

En pratique, n’importe qui peut se connecter en SSH à une machine Alpine vulnérable en envoyant un mot de passe de 257 caractères ou plus, pour tout compte dont le champ password dans /etc/shadow vaut « * ». Sur les images Alpine Linux standards utilisées en cloud et dans Docker, le compte root ou un compte de service par défaut remplit souvent cette condition. Les chercheurs de Previdian ont confirmé l’exploitation sur un honeypot Alpine moins de 9 heures après la divulgation publique — un délai record même pour 2026.

L’impact potentiel est considérable : Alpine Linux est l’image de base officielle de milliers de projets open source (Python, Node.js, Golang, Redis, Nginx sur Alpine…) et est massivement déployée dans des environnements Kubernetes. Selon les statistiques Docker Hub, les images basées sur Alpine cumulent des milliards de téléchargements. SonarSource estime que plus de 60 % des pipelines CI/CD professionnels utilisent au moins une image Alpine dans leurs étapes de build ou de test.

D’autres systèmes basés sur musl libc sont également concernés : OpenWrt (routeurs domestiques et professionnels), Buildroot et Yocto (systèmes embarqués industriels). Ces plateformes n’avaient pas publié de statut de correctif au 6 novembre 2026, ce qui élargit la surface d’attaque à des équipements IoT et des infrastructures OT souvent moins bien surveillés.

Alpine Linux a réagi avec une rapidité remarquable : les paquets openssh patchés (10.6_p2-r0 pour Alpine edge, 10.3_p1-r2 pour la branche 3.24) ont été publiés le jour même de la divulgation. OpenSSH 10.6p2 corrige le problème en modifiant la gestion des mots de passe longs dans sshd pour éviter le faux positif généré par musl.

Un point opérationnel critique : mettre à jour le paquet openssh sur Alpine ne suffit pas. Le processus sshd en cours d’exécution continue de faire tourner le code vulnérable jusqu’à son redémarrage explicite. La commande rc-service sshd restart (ou service sshd restart) est indispensable après l’upgrade. Dans les environnements Kubernetes, les pods utilisant Alpine doivent être recréés — un rolling restart ne garantit pas la mise à jour de l’image de base si celle-ci est épinglée à un tag mutable comme :latest ou :3.24.

Le CERT-FR a publié l’alerte CERTFR-2026-ALE-015 le 5 novembre, mise à jour le 6 novembre, recommandant de vérifier les configurations exposées et d’appliquer les correctifs de l’éditeur. Au 10 novembre, CVE-2026-123158 ne figurait pas encore dans le catalogue KEV de la CISA, mais l’exploitation active confirmée laisse anticiper son ajout prochainement. Le score CVSS est de 8.1 (High) — ce qui sous-estime en pratique la criticité sur les environnements cloud-native où la combinaison compte sans mot de passe + SSH exposé aboutit directement à un accès root.

Impact et exposition

Sont exposés tous les systèmes faisant tourner OpenSSH inférieur à la version 10.6p2 sur Linux avec musl libc sans PAM, avec le service SSH accessible depuis le réseau. En pratique : images Docker et Kubernetes basées sur Alpine, appliances réseau OpenWrt, systèmes industriels embarqués (Buildroot, Yocto). Les comptes ciblés sont ceux dont /etc/shadow contient « * » comme hash de mot de passe — typiquement les comptes système, root désactivé, et comptes de service créés sans mot de passe explicite.

Recommandations

  • Mettre à jour le paquet openssh sur toutes les instances Alpine (apk update && apk upgrade openssh) et redémarrer sshd immédiatement après
  • En attente de patch : désactiver l’authentification par mot de passe (PasswordAuthentication no dans sshd_config) et n’autoriser que les clés SSH
  • Reconstruire les images Docker et Kubernetes basées sur Alpine avec l’image de base mise à jour — ne pas se contenter d’un restart de pod si l’image n’est pas re-pull
  • Auditer /etc/shadow sur les systèmes Alpine exposés : identifier les comptes avec « * » ou « ! » comme hash et les désactiver ou leur attribuer un mot de passe fort
  • Vérifier les équipements réseau sous OpenWrt et les systèmes embarqués Buildroot/Yocto pour évaluer leur exposition

Alerte critique

CVE-2026-123158 est exploitée activement dans la nature depuis le 5 novembre 2026. Sur les images Alpine Docker exposées avec SSH ouvert, un attaquant peut obtenir un shell root en quelques secondes sans aucune connaissance du mot de passe. Patcher et redémarrer sshd immédiatement.

Mon image Docker basée sur Alpine est-elle vulnérable même si je n’expose pas le port SSH ?

Si le service sshd n’est pas démarré dans votre conteneur, vous n’êtes pas exposé directement à CVE-2026-123158. Cependant, si un attaquant compromet un autre vecteur dans votre pipeline et obtient un accès au nœud Kubernetes ou au pod, il peut déclencher sshd et exploiter la faille en lateral movement. Reconstruire l’image avec Alpine patchée reste la bonne pratique, même pour les conteneurs sans SSH actif.

Votre infrastructure est-elle exposée ?

Ayi NEDJIMI réalise des audits de sécurité ciblés pour identifier et corriger vos vulnérabilités avant qu’elles ne soient exploitées.

Demander un audit