OpenSSH « SSHole » : une faille exploitée sur Alpine

Le 5 novembre 2026, OpenSSH a publié la version 10.6p2 avec un correctif d'urgence. La faille, CVE-2026-123158, surnommée « SSHole », permet d'ouvrir une session SSH sans connaître le mot de passe, sur certains systèmes Linux qui utilisent la bibliothèque musl sans PAM. Alpine Linux est l'exemple type. Des tentatives d'exploitation ont été observées dès le lendemain, et la CISA l'a inscrite au catalogue KEV le 9 novembre.

Ce qui s'est passé

La faille. Selon les notes de version d'OpenSSH, sshd contenait un contournement de l'authentification par mot de passe sur certains systèmes Linux compilés et exécutés sans PAM. L'équipe d'OpenSSH situe la cause en dehors de sshd, mais la faille s'exploite par sshd et peut y être évitée. La NVD précise que, pour certaines configurations de comptes, n'importe quel mot de passe de 256 à 1 024 caractères est accepté. Le score CVSS est de 8,1.

Les conditions. L'avis d'Alpine détaille ce qu'il faut pour être touché :

• le paquet openssh-server d'Alpine, compilé sans PAM, ou openssh-server-pam avec UsePAM no ;
• PasswordAuthentication à yes, la valeur par défaut d'OpenSSH ;
• un compte dont le champ de mot de passe vaut « * », ce qui est normal pour un compte qui se connecte seulement par clé ;
• au moins un autre compte local avec un hachage de type $5$ ou $6$.

Alpine résume : un attaquant qui atteint le port SSH peut se connecter sans mot de passe, en une seule connexion, à chaque fois. Toutes les versions vérifiées sont touchées, de 3.16 à 3.24 et edge. Alpine ajoute que root est livré avec « * » dans l'image de base depuis environ la version 3.16, protégé par défaut par PermitRootLogin prohibit-password, mais qu'un autre compte capable de devenir root, par exemple avec doas, suffit.

Qui n'est pas touché. Toujours selon Alpine : les conteneurs qui n'exécutent pas sshd, les systèmes avec PasswordAuthentication no, ceux qui utilisent PAM avec UsePAM yes, les comptes verrouillés par « ! » et les images infonuagiques configurées par cloud-init, qui désactive l'authentification par mot de passe.

L'exploitation. Previdian indique avoir capté de premières tentatives le 6 novembre, moins d'une journée après la publication de la CVE. Elle précise que ces tentatives ne prouvent pas que les cibles étaient vulnérables ni que l'attaque a réussi. La CISA a ajouté la faille au KEV le 9 novembre, avec une échéance au 12 novembre et un triage forensique requis. Le Centre canadien pour la cybersécurité l'a relayée dans son bulletin AV26-1130.

Pourquoi ça compte

Alpine est partout où on ne le voit pas. C'est une distribution légère, très utilisée pour les images de conteneurs, les machines virtuelles minimales et les appliances. Beaucoup d'équipes ne savent pas qu'un équipement réseau, un outil de sauvegarde ou une machine de test tourne sur Alpine. Un inventaire qui s'arrête au système d'exploitation principal ne verra pas ce serveur SSH.

Les comptes « sans mot de passe » deviennent la porte. La faille vise justement les comptes qu'on croit les plus sûrs, ceux qui n'acceptent qu'une clé. Un seul compte avec un vrai mot de passe sur la machine suffit à rendre tous les autres accessibles.

Le délai entre divulgation et exploitation se compresse. Les notes d'OpenSSH le disent : l'équipe reçoit beaucoup de rapports de failles trouvées avec l'aide de l'IA, et des chercheurs différents trouvent souvent la même faille de façon indépendante. L'équipe en conclut que des attaquants peuvent probablement les trouver aussi, et publiera désormais des correctifs plus souvent. Pour vous, cela veut dire moins de temps entre l'avis et le besoin d'agir.

Ce que nous en pensons chez Sentrix

1. Trouvez vos serveurs SSH sur musl. Cherchez les hôtes Alpine, et plus largement les images et appliances bâties sur musl, qui exposent le port 22. Notre module CTEM relie l'exposition au système réel derrière chaque port.
2. Mettez à jour, puis redémarrez sshd. Alpine fournit les versions corrigées par branche. Le redémarrage du démon est l'étape qu'on oublie.
3. Désactivez l'authentification par mot de passe en SSH. C'est la mesure de contournement d'Alpine et une bonne pratique en soi : les serveurs se gèrent par clé ou par certificat. Notre service postes et serveurs intègre ce réglage aux gabarits de durcissement.
4. Cherchez les connexions suspectes. Alpine recommande de chercher dans /var/log/messages les entrées « Accepted password for » sur des comptes sans mot de passe, et de revoir doas, les comptes récents et les clés autorisées. Une machine où une connexion ne peut pas être exclue est à traiter comme compromise.
5. Demandez à vos fournisseurs. Si une appliance embarque OpenSSH sur Alpine, c'est au fournisseur de livrer le correctif. Une nomenclature logicielle permet de poser la question en connaissant déjà la réponse.
6. Raccourcissez la boucle KEV. Trois jours séparaient l'inscription au catalogue de l'échéance fédérale. Comparez le flux KEV à votre inventaire chaque jour, comme le décrit notre article sur la priorisation avec le catalogue KEV, et appuyez le cycle sur notre service vulnérabilités et correctifs.

La prochaine étape

Lancez aujourd'hui une recherche sur tous vos hôtes pour une seule ligne : la valeur effective de PasswordAuthentication dans sshd. Chaque « yes » sur un système Alpine est à corriger avant la fin de la semaine. Pour faire cet inventaire avec nous, contactez-nous.