CVE-2026-123158 : contournement de l'authentification par mot de passe d'OpenSSH sur Alpine Linux

Contexte

OpenSSH a publié le 5 novembre 2026 une version corrective, 10.6p2, pour une vulnérabilité de sshd signalée la veille par Özgün Kültekin, chercheur chez Wakefield. Elle porte l'identifiant CVE-2026-123158, et le chercheur l'a surnommée « sshole ».

La faille permet de se connecter par mot de passe à un compte qui n'en a pas. Elle ne concerne que les systèmes Linux bâtis sur la bibliothèque C musl dont sshd vérifie les mots de passe sans passer par PAM.

C'est la configuration par défaut d'Alpine Linux, qui concentre donc l'essentiel du risque. Debian, Ubuntu, RHEL et les autres distributions sous glibc ne sont pas touchées.

Alpine a publié son avis le même jour, avec des paquets corrigés pour toutes ses branches depuis la 3.16. Aucune exploitation n'a été signalée au moment où nous écrivons.

Fiche technique

La note de 8,1 tient à une complexité d'attaque cotée élevée (AC:H). OpenSSH, de son côté, qualifie le correctif de « critique » dans ses notes de version.

Nous lisons ce AC:H comme le reflet des conditions de configuration, et non d'une difficulté technique. Sur un hôte qui les remplit, l'avis d'Alpine décrit une attaque déterministe, qui réussit au premier essai.

Pour un serveur concerné, nous la traiterions donc comme une faille critique. Nous revenons sur ces écarts entre score et risque réel dans notre article sur la priorisation des vulnérabilités.

Systèmes concernés

L'avis d'Alpine pose quatre conditions, qui doivent toutes être réunies :

1. sshd vérifie les mots de passe sans PAM. C'est le cas du paquet openssh-server d'Alpine ; la variante openssh-server-pam n'est concernée qu'avec UsePAM no.
2. L'authentification par mot de passe est active (PasswordAuthentication yes, valeur par défaut d'OpenSSH).
3. Au moins un compte a * pour champ de mot de passe. Sur Alpine, c'est le cas de root dans les images de base, des comptes créés pour une connexion par clé seulement, et de certains comptes issus d'un annuaire.
4. Au moins un autre compte local possède une empreinte réelle, au format $5$ ou $6$.

Ne sont pas concernés :

• les distributions sous glibc (Debian, Ubuntu, RHEL et dérivés, Fedora), ainsi que macOS et OpenBSD ;
• tout sshd qui vérifie les mots de passe via PAM ;
• les serveurs configurés en PasswordAuthentication no ;
• les comptes verrouillés par ! plutôt que par * ;
• Dropbear, le serveur SSH par défaut d'OpenWrt, et les autres programmes de connexion par mot de passe, d'après le mainteneur de musl ;
• les conteneurs Alpine qui ne font pas tourner sshd, c'est-à-dire la très grande majorité.

Le compte root

Dans les images Alpine, root a bien * pour mot de passe depuis la 3.16. Il reste protégé par la valeur par défaut PermitRootLogin prohibit-password, qui refuse à root toute connexion par mot de passe.

Un serveur sur lequel cette directive a été passée à yes expose en revanche root directement. C'est le premier réglage que nous vérifierions.

Images cloud officielles

Les images « tiny-cloud » d'Alpine (qcow2, VHD, AMI), de la 3.18.11 à la 3.24.3, créent un utilisateur alpine. Son champ de mot de passe vaut *, il dispose de doas sans mot de passe, et il porte le même nom sur toutes les instances.

Une instance qui vient de démarrer n'est pas vulnérable, faute de compte doté d'un vrai mot de passe. Elle le devient dès qu'une empreinte $6$ apparaît sur la machine :

• un mot de passe défini pour l'accès console ;
• un hashed_passwd passé dans les user-data ;
• un compte de service créé à la main.

C'est à notre avis le cas le plus sérieux, car la condition manquante s'obtient par une opération d'administration tout à fait courante.

Les images construites à partir des versions 3.21.10, 3.22.8, 3.23.8 et 3.24.4 intègrent le correctif. Les instances déjà en service, elles, se mettent à jour une par une. Alpine précise que les images qui passent par cloud-init écrivent PasswordAuthentication no et ne sont pas concernées.

Conteneurs et systèmes embarqués

Un conteneur Alpine n'est exposé que s'il fait tourner un serveur SSH avec les mots de passe actifs : conteneur de rebond, serveur SFTP, image « SSH prêt à l'emploi ». Le cas est rare, mais il existe.

Mettre le paquet à jour à l'intérieur du conteneur ne règle rien durablement, puisque le prochain redéploiement ramène l'ancienne version. Il faut reconstruire l'image depuis une base corrigée.

Les systèmes Buildroot ou Yocto, et les routeurs OpenWrt où OpenSSH a remplacé Dropbear, sont dans la même situation qu'Alpine s'ils remplissent les quatre conditions. Pour un équipement dont vous ne maîtrisez pas le micrologiciel, interrogez le fournisseur et désactivez l'authentification par mot de passe si l'interface le permet.

Fonctionnement

Pour trouver la faille, Özgün Kültekin a compilé sshd dans toutes les combinaisons possibles : glibc ou musl, avec ou sans PAM, avec ou sans fichier shadow. Il a ensuite soumis chaque variante à environ 17 600 tentatives de connexion inhabituelles, générées à l'aide d'agents IA.

Une seule combinaison a répondu différemment des autres : musl sans PAM. Le défaut vient de trois choix faits séparément, sur dix ans :

• En 2012, musl fait renvoyer à crypt() la chaîne * en cas d'échec, plutôt que NULL. Trois semaines plus tard, la bibliothèque ajoute SHA-crypt, avec une clé limitée à 256 octets ; au-delà, crypt() échoue.
• En 2016, OpenSSH corrige CVE-2016-6210, une énumération de comptes par mesure du temps de réponse. Depuis, sshd calcule une empreinte même pour un compte qui n'en a pas de valide, en reprenant le sel d'un autre compte du système. C'est l'origine de la quatrième condition.
• En 2022, Alpine 3.16 attribue * à root au lieu de !. Sans PAM, ! bloquait aussi la connexion par clé, un problème ouvert depuis CVE-2019-5021.

Sans PAM, sshd calcule l'empreinte du mot de passe reçu et la compare, chaîne contre chaîne, au champ de /etc/shadow. Sous musl, un mot de passe de plus de 256 octets fait échouer ce calcul, qui renvoie *. Si le champ du compte vaut lui aussi *, la comparaison réussit.

Sous glibc, crypt() signale l'échec autrement et sshd refuse déjà ce cas. Avec PAM, crypt() n'est jamais appelée pour un compte à *.

Le correctif ajoute une garde dans sys_auth_passwd() : aucune correspondance n'est acceptée si l'empreinte stockée compte moins de quatre caractères (MIN_PASSWORD_HASH_LEN). Aucune empreinte réelle n'est aussi courte, alors que les marqueurs d'absence de mot de passe (*, !, x) le sont tous.

Les deux projets ne s'accordent pas sur la responsabilité :

• OpenSSH écrit : « nous considérons que la cause première de ce bug se trouve hors de sshd, mais il est exploitable par sshd et peut y être évité » ;
• Rich Felker, mainteneur de musl, estime qu'il ne s'agit « pas d'un bug de musl, juste d'une utilisation erronée par l'appelant », tout en annonçant que ce comportement changera « très probablement » au prochain cycle de versions.

En pratique, le correctif à déployer est celui d'OpenSSH. Une machine musl dont OpenSSH n'est pas à jour reste exposée, quelle que soit sa version de musl.

Paquets Alpine corrigés

Alpine a rétroporté le correctif sur toutes ses branches depuis la 3.16, y compris celles qui ne sont plus maintenues (3.16 à 3.20).

Vérification sur l'hôte

La vérification se fait en local, en root. Nous déconseillons de tester une connexion pour juger de l'exposition, comme de lancer les scripts de détection non audités qui circulent depuis le 5 novembre (OX Security a mis en garde à leur sujet).

Bibliothèque C et paquet installé

cat /etc/alpine-release                      # Alpine, et quelle version
ldd /usr/sbin/sshd | grep -i musl            # sshd lié à musl ?
apk info -v 2>/dev/null | grep '^openssh-server'

Comparez ensuite la version du paquet au tableau ci-dessus.

Configuration effective de sshd

sshd -T | grep -Ei '^(usepam|passwordauthentication|permitrootlogin)'

Deux remarques sur ce résultat :

• un sshd compilé sans PAM n'affiche aucune ligne usepam, ce qui est normal ;
• sshd -T donne la configuration globale, alors qu'un bloc Match peut réactiver les mots de passe pour un utilisateur ou un réseau. Relisez le fichier, ou testez un cas précis avec sshd -T -C user=alpine,host=exemple,addr=203.0.113.10.

Comptes concernés

awk -F: '$2 == "*" {print "sans mot de passe :", $1}' /etc/shadow
awk -F: '$2 ~ /^\$[56]\$/ {print "empreinte réelle :", $1}' /etc/shadow

L'hôte était exploitable si les deux listes sont non vides, que les mots de passe sont actifs et que le paquet n'est pas corrigé.

Au-delà de root, regardez en priorité les comptes de service et de déploiement réservés aux clés, ainsi que le compte alpine des images cloud.

Remédiation

Par ordre d'efficacité :

1. Mettre à jour, puis redémarrer sshd. L'avis d'Alpine le rappelle : la mise à jour du paquet ne remplace pas le démon en cours d'exécution.

   apk upgrade -U -a
   rc-service sshd restart

2. Désactiver l'authentification par mot de passe si la mise à jour ne peut pas être immédiate. Vérifiez d'abord que la connexion par clé fonctionne, et gardez une session ouverte pendant la manipulation. Méthode publiée par Alpine :

   mkdir -p /etc/ssh/sshd_config.d
   echo 'PasswordAuthentication no' > /etc/ssh/sshd_config.d/00-no-passwords.conf
   sed -i.bak -e '1i PasswordAuthentication no' \
     -e 's/^\(\s*PasswordAuthentication[^y#]*\)yes/\1no/i' \
     /etc/ssh/sshd_config
   sshd -t && rc-service sshd restart
   sshd -T | grep -i passwordauthentication     # doit afficher : passwordauthentication no

   Le répertoire sshd_config.d n'est lu par défaut qu'à partir d'Alpine 3.19, d'où la modification du fichier principal, qui couvre aussi les blocs Match. L'original est conservé dans sshd_config.bak.
3. Reconstruire les images qui embarquent openssh-server (images Docker, modèles de VM, AMI internes) à partir d'une base corrigée. Pour administrer un conteneur, docker exec ou kubectl exec évitent d'y faire tourner un serveur SSH.
4. Limiter l'exposition : filtrage par pare-feu ou accès par VPN, et retrait du doas sans mot de passe du compte alpine là où il ne sert pas.

Nous recommandons de conserver PasswordAuthentication no une fois le paquet corrigé. Un serveur SSH joignable depuis Internet a rarement besoin d'accepter des mots de passe, et s'en passer élimine du même coup les attaques par force brute.

Une dernière mesure circule : remplacer * par ! dans /etc/shadow. Elle bloque l'attaque, mais sans PAM, OpenSSH considère alors le compte comme verrouillé et refuse aussi la connexion par clé. C'est précisément ce qui avait conduit Alpine à passer de ! à * en 2022 ; nous la réservons aux comptes qui ne servent jamais à se connecter.

Recherche de compromission

Aucun indicateur réseau n'a été publié. La trace exploitable se trouve dans les journaux d'authentification :

• sur Alpine, /var/log/messages et ses archives. Une ligne sshd « Accepted password for » portant sur un compte sans mot de passe (alpine, root, compte réservé aux clés) n'a pas d'explication légitime ;
• la collecte centralisée, seule source pour les conteneurs et les instances déjà détruits.

Si une telle ligne apparaît, ou si les journaux ne permettent pas de conclure sur un hôte exposé, nous traiterions la machine comme compromise :

• revue de l'usage de doas, des comptes récents, des fichiers modifiés et des authorized_keys ;
• reconstruction de la machine plutôt que nettoyage ;
• renouvellement des secrets qu'elle détenait (clés, jetons, mots de passe vers d'autres systèmes).

Chronologie

OpenSSH a été prévenu le 4 novembre et a publié le correctif le lendemain, sans le délai qu'on laisse d'ordinaire aux distributions pour se préparer.

Damien Miller s'en est expliqué sur la liste des développeurs d'OpenSSH. L'équipe a constaté « de multiples cas de redécouverte rapide de bugs par des agents IA, parfois en quelques heures », et considère désormais un long embargo comme « une pratique dangereuse qui profite surtout aux attaquants ».

Nous décrivions la veille, à propos de CVE-2026-98432, un exploit root à distance écrit par un modèle d'IA en moins d'une heure. Les deux cas vont dans le même sens : le temps de préparation entre un correctif et son exploitation possible se réduit.

Détection depuis l'extérieur

Flawfence ne tente aucune authentification sur vos serveurs SSH, et ce test n'apporterait rien que la vérification locale ne fasse mieux. La faille se prête d'ailleurs mal à une détection à distance :

• la bannière SSH donne la version d'OpenSSH, pas la bibliothèque C ni l'usage de PAM ;
• les paquets Alpine corrigés conservent leur numéro de version amont, si bien que la bannière ne distingue pas un serveur corrigé d'un serveur vulnérable.

Notre rôle se situe en amont. Flawfence recense les serveurs SSH exposés sur Internet en votre nom, situe leurs versions observables quand c'est possible, et signale ceux qui apparaissent ou réapparaissent après une migration.

Avec cette liste, le jour d'un avis comme celui-ci, on sait en une heure quelles machines vérifier. Elle se construit avant la faille, en cartographiant son système d'information et en inventoriant sa surface d'attaque externe en continu.

Questions fréquentes sur CVE-2026-123158

Qu'est-ce que CVE-2026-123158 ?

Un contournement de l'authentification par mot de passe dans sshd, le serveur d'OpenSSH, surnommé « sshole ». Sur Linux avec musl et sans PAM, un compte sans mot de passe (* dans /etc/shadow) peut accepter une connexion avec un mot de passe très long. La faille est notée 8,1 en CVSS 3.1 et corrigée dans OpenSSH 10.6p2.

Mon serveur Debian, Ubuntu ou RHEL est-il concerné ?

Non. Ces distributions utilisent glibc et PAM, et ne remplissent pas les conditions. Red Hat confirme qu'aucun de ses produits n'est touché. La faille concerne les systèmes musl, Alpine Linux en tête.

Mes conteneurs Docker basés sur Alpine sont-ils vulnérables ?

Seulement s'ils font tourner un serveur SSH qui accepte les mots de passe, ce qui est rare. Dans ce cas, reconstruisez l'image depuis une base corrigée plutôt que de mettre à jour le conteneur en place.

Quelle version corrige la faille ?

OpenSSH 10.6p2 en amont. Sur Alpine, le paquet openssh corrigé dépend de la branche : 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 ainsi de suite jusqu'à la 3.16. Redémarrez sshd après la mise à jour.

Comment se protéger sans mettre à jour tout de suite ?

En désactivant l'authentification par mot de passe (PasswordAuthentication no), après avoir vérifié que la connexion par clé fonctionne, puis en redémarrant sshd. OpenSSH et le mainteneur de musl recommandent tous deux cette mesure.

La faille est-elle exploitée ?

Aucune exploitation n'a été signalée au 6 novembre 2026, et la faille ne figure pas au catalogue KEV de la CISA. Des environnements de reproduction sont toutefois publics, et la CISA situe l'exploitation au stade de la preuve de concept.

Comment savoir si un attaquant s'est connecté ?

Cherchez dans les journaux de sshd les lignes « Accepted password for » portant sur un compte sans mot de passe (alpine, root, comptes réservés aux clés). Une telle ligne n'a pas d'explication légitime : la machine est à traiter comme compromise.

Sources

• Fiche CVE-2026-123158 (cve.org) et NVD
• OpenSSH, notes de version 10.6p2
• Commit 4353fdc « avoid password authn bypass »
• Alpine Linux, « Security advisory: openssh-server password authentication bypass »
• Damien Miller sur openssh-unix-dev
• oss-security, « "sshole": password authentication bypass: OpenSSH + musl libc »
• Rich Felker, « Advisory for OpenSSH+musl users » (liste musl)
• Özgün Kültekin, sshhole.com
• Red Hat, CVE-2026-123158
• LWN, « Critical security vulnerability affects OpenSSH on Alpine Linux systems »
• OX Security, « OpenSSH Password Authentication Bypass on Alpine Linux »
• CISA, catalogue Known Exploited Vulnerabilities