Une faille d’authentification d’OpenSSH peut permettre un accès SSH non autorisé sur certains systèmes Linux qui utilisent musl libc sans PAM. Des tentatives d’exploitation ont été observées. Les administrateurs doivent vérifier leur exposition, appliquer le correctif du fournisseur et redémarrer le démon SSH.
Le 5 novembre 2026, OpenSSH a publié la version 10.6p2 pour corriger un contournement de l’authentification par mot de passe. Le problème, référencé sous l’identifiant CVE-2026-123158, peut permettre à un attaquant d’accéder à certains comptes sans connaître de mot de passe valide. Alpine Linux est une distribution concernée particulièrement importante, car son paquet standard de serveur OpenSSH est compilé sans PAM.
Alpine repose également sur musl, une bibliothèque C standard compacte. Une bibliothèque C est l’ensemble des fonctions de base sur lesquelles s’appuient les programmes, y compris celle qui calcule l’empreinte des mots de passe. Les versions compilées par Red Hat utilisent une autre bibliothèque, glibc, ce qui aura son importance plus loin dans cet article.
Il ne s’agit pas d’une compromission universelle d’OpenSSH. Un système vulnérable doit réunir plusieurs conditions liées à l’authentification et aux comptes. Mais sur les systèmes concernés, un accès non autorisé à un compte peut ouvrir la voie à des fichiers sensibles ou à des privilèges élevés.
Les notes de version d’OpenSSH confirment la solution de contournement (workaround). L’avis d’Alpine du 5 novembre identifie les configurations concernées, les paquets corrigés et les mesures correctives requises.
La vulnérabilité en bref
| Élément | Ce que disent les sources |
|---|---|
| Identifiant | CVE-2026-123158 |
| Divulgation | 5 novembre 2026 (publication d’OpenSSH et avis d’Alpine, qui indiquait qu’aucun identifiant CVE n’avait encore été attribué) |
| Faiblesse | Contournement de l’authentification par mot de passe |
| Systèmes concernés | OpenSSH utilisant musl libc avec PAM désactivé, lorsque les conditions supplémentaires ci-dessous sont réunies |
| Effet potentiel | Connexion non autorisée à un compte, éventuellement suivie d’une élévation de privilèges (privilege escalation) lorsque les permissions du compte le permettent |
| Correction en amont | Portable OpenSSH 10.6p2 |
| Activité | Observations de pots de miel (honeypots) compatibles avec des tentatives d’exploitation, sans preuve d’une compromission généralisée |
| Mesures administratives | Évaluer la configuration, mettre à jour les paquets, redémarrer sshd (le programme serveur SSH), examiner toute activité d’authentification suspecte |
Les conditions qui font qu’un système est concerné
Pour la configuration concernée, Alpine identifie toutes les conditions suivantes :
- Le serveur SSH utilise le chemin d’authentification sans PAM. Cela inclut le paquet
openssh-serverd’Alpine, ou sa version compatible PAM configurée avecUsePAM no. PasswordAuthentication yesautorise le chemin de connexion par mot de passe en question.- Un compte cible comporte
*dans son champ de mot de passe. Ces comptes peuvent être destinés à un accès par clé SSH plutôt qu’à une connexion par mot de passe. - Au moins un autre compte local possède une empreinte de mot de passe
$5$(SHA-256) ou$6$(SHA-512). - Un attaquant peut atteindre le service SSH et dispose d’un nom de compte cible utilisable.
PAM signifie Pluggable Authentication Modules. Il s’agit d’un cadre qui permet aux applications d’utiliser les mécanismes d’authentification configurés. Le comportement en cause passe par un chemin différent lorsque PAM est désactivé.
Un système n’est pas exposé par ce chemin précis du seul fait qu’il utilise Alpine ou qu’il contient la bibliothèque musl. Les conteneurs qui n’exécutent pas sshd ne sont pas concernés en tant que serveurs SSH. Alpine cite PasswordAuthentication no et un serveur avec PAM activé par UsePAM yes parmi les configurations non concernées par ce problème.
Red Hat indique que ses produits, dont RHEL, ne sont pas concernés, car leurs versions compilées d’OpenSSH sont liées à glibc et utilisent PAM par défaut. Sources : avis d’Alpine et évaluation de la CVE par Red Hat.
Comment fonctionne le contournement
Linux stocke généralement une empreinte de mot de passe (password hash), une valeur dérivée du mot de passe, plutôt que le mot de passe d’origine. Certains comptes n’ont volontairement aucune empreinte de mot de passe utilisable. Leur champ de mot de passe peut alors contenir un marqueur spécial, *, qui ne devrait permettre aucune connexion par mot de passe.
La fonction crypt() de la bibliothèque musl peut aussi renvoyer * comme indication d’erreur lorsqu’elle reçoit un mot de passe d’une longueur inhabituelle. Dans le chemin vulnérable de vérification des mots de passe d’OpenSSH sans PAM, ce résultat d’erreur peut être confondu avec une correspondance avec le marqueur * enregistré pour un compte. La présence supplémentaire d’un autre compte local utilisant une empreinte de mot de passe compatible fait partie des conditions signalées.
Il en résulte une grave défaillance de la frontière de confiance (trust boundary) : une erreur provenant d’une bibliothèque de plus bas niveau peut être traitée comme la preuve d’une authentification réussie, alors même que le compte n’a aucun mot de passe valide. Les notes de version d’OpenSSH 10.6p2 indiquent que la cause profonde se situe en dehors de sshd, mais que le comportement dangereux peut y être empêché.
Cette vulnérabilité illustre une règle générale de sécurité logicielle : un statut d’erreur ne doit jamais être interprété comme une autorisation ou une authentification réussie.
Observations d’exploitation et ce qu’elles prouvent
Le 8 novembre, le SANS Internet Storm Center a fait état d’une activité de mots de passe longs recueillie par ses pots de miel SSH Cowrie, des serveurs leurres qui enregistrent ce que tentent les attaquants. Les décomptes publiés étaient de 58 le 4 novembre, 232 le 5 novembre, 713 le 6 novembre, 246 le 7 novembre et 51 le 8 novembre, à la mise à jour du rapport de 15 h 44 UTC.
Il s’agit d’observations de mots de passe longs, et non de compromissions réussies vérifiées, ni même de tentatives exclusivement liées à cette CVE. SANS précise qu’une partie de l’activité antérieure était sans rapport. Il a identifié le 5 novembre comme la première utilisation reconnaissable du schéma propre à la vulnérabilité. Le décompte partiel du 8 novembre n’est pas directement comparable aux journées complètes précédentes.
Cette observation suffit à établir l’intérêt des attaquants et à justifier une action défensive rapide. Elle ne permet pas d’établir le volume d’exploitation à l’échelle mondiale ni le nombre de systèmes de production compromis.
Versions corrigées et atténuation immédiate
La correction de sécurité en amont figure dans OpenSSH 10.6p2. Les distributeurs Linux peuvent rétroporter ce correctif (backport), c’est-à-dire l’appliquer à des paquets qui portent des numéros de version amont antérieurs.
Alpine a publié les révisions de paquets corrigées suivantes :
| Branche Alpine | Paquet OpenSSH corrigé |
|---|---|
| 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 |
D’autres branches plus anciennes figurent dans la matrice complète des correctifs d’Alpine. Vérifiez l’avis réel de la distribution et la révision du paquet installé plutôt que de supposer que toute version inférieure à 10.6p2 n’est pas corrigée.
Pour Alpine, l’avis indique la séquence suivante de mise à jour et de redémarrage du service :
apk upgrade -U -a
rc-service sshd restartLe redémarrage du démon en cours d’exécution est indispensable. Alpine avertit explicitement que la mise à jour d’un paquet ne remplace pas le processus sshd déjà en cours d’exécution. Appliquez les modifications dans le cadre d’une procédure de maintenance autorisée, avec une console confirmée ou un autre chemin d’administration.
Si l’application du correctif doit être retardée, Alpine recommande de désactiver l’authentification SSH par mot de passe en définissant PasswordAuthentication no dans la configuration effective de sshd. Avant de redémarrer ou de recharger le service, vérifiez l’accès par clé SSH et conservez une session d’administration fonctionnelle pour ne pas vous retrouver bloqué. Il s’agit d’une atténuation temporaire, et non d’une raison de reporter indéfiniment la mise à jour de sécurité.
Rechercher un éventuel accès non autorisé
L’application du correctif bloque le chemin vulnérable connu pour l’avenir. Elle n’annule pas une connexion non autorisée antérieure.
Pour les systèmes qui réunissaient les conditions d’exposition, examinez les journaux d’authentification SSH à la recherche de connexions réussies par mot de passe sur des comptes censés n’accepter que des clés. Recherchez également les modifications inexpliquées de comptes ou de clés autorisées, toute activité d’élévation de privilèges et les modifications de fichiers suspectes. Un seul événement inattendu dans les journaux mérite une investigation, mais ne constitue pas, à lui seul, la preuve que cette CVE a été exploitée. Notre article sur ce qu’il faut faire après avoir corrigé une faille déjà exploitée applique le même principe aux équipements de périphérie : un correctif ne vous dit pas qui est passé avant lui.
Alpine signale une préoccupation supplémentaire pour certaines images officielles tiny-cloud, les images de machines virtuelles cloud d’Alpine. Leur compte alpine peut n’avoir aucun mot de passe utilisable tout en disposant de privilèges doas sans mot de passe (doas est un outil qui permet à un utilisateur d’exécuter des commandes en tant qu’administrateur). Ces images ne sont pas nécessairement exploitables au premier démarrage, mais la combinaison en cause d’états du compte et de l’empreinte de mot de passe peut aggraver l’impact.
Alpine indique que les images construites à partir de 3.21.10, 3.22.8, 3.23.8 et 3.24.4 ou de versions ultérieures incluent le paquet corrigé. Les instances démarrées à partir d’images antérieures ont toujours besoin de la mise à jour du paquet ou de la modification du paramètre de mot de passe. Consultez les recommandations d’Alpine sur l’impact et la détection.
Ce que les administrateurs doivent faire maintenant
Les organisations qui exploitent Alpine ou d’autres déploiements SSH concernés basés sur musl peuvent suivre cinq étapes :
- Déterminer si les conditions documentées sont réunies.
- Appliquer le paquet corrigé du fournisseur.
- Redémarrer le démon SSH lui-même, c’est-à-dire le processus en cours d’exécution.
- Vérifier la configuration d’authentification effective.
- Examiner les journaux d’authentification lorsqu’une exposition antérieure est plausible.
Rien ne permet de considérer toute installation d’OpenSSH comme compromise. Rien ne permet non plus de supposer qu’un compte accessible uniquement par clé SSH est protégé si le serveur autorise encore un chemin vulnérable d’authentification par mot de passe. Les équipes qui n’exécutent aucun serveur SSH sur Alpine ou sur un autre système musl n’ont aucune mesure à prendre pour ce problème précis et peuvent le traiter comme une étude de cas.
La priorité immédiate est une évaluation propre à chaque configuration, l’application des correctifs du fournisseur et la vérification du service en cours d’exécution.
Pour aller plus loin
- Alpine Linux security advisory, 5 novembre 2026 : configurations concernées, explication technique, versions corrigées, remédiation et détection.
- OpenSSH portable 10.6p2 release notes, 5 novembre 2026 : solution de contournement en amont et limites techniques.
- Évaluation de CVE-2026-123158 par Red Hat : applicabilité propre à chaque distribution.
- SANS ISC, 8 novembre 2026 : balayages observés et limites des éléments de preuve.