Passer au contenu principal
Publié le 13 novembre 2026
CVE-2026-123158 — OpenSSH sshd, systèmes musl sans PAM. La faille permet de se connecter en SSH sans connaître le mot de passe. Elle est exploitée : la CISA l’a ajoutée à son catalogue des vulnérabilités activement exploitées (KEV) le 9 novembre 2026. Les VPS Debian, Ubuntu et AlmaLinux ne sont pas touchés. Vérifiez en revanche vos machines et conteneurs Alpine qui exposent sshd.

Le problème en deux phrases

Compilé sans PAM, sshd vérifie un mot de passe en le hachant avec la fonction crypt() de la bibliothèque C, puis en comparant le résultat au champ stocké dans /etc/shadow. Avec la bibliothèque musl, crypt() renvoie * quand le mot de passe dépasse 256 octets : c’est justement le contenu du champ des comptes sans mot de passe, et la connexion est acceptée. Versions touchées :
  • OpenSSH avant 10.6p2, sur Linux, compilé avec musl et sans PAM ;
  • Alpine Linux, toutes les branches de 3.16 à 3.24 et edge, selon l’avis Alpine.
Le correctif est sorti le 5 novembre 2026 : OpenSSH 10.6p2, et des paquets corrigés pour chaque branche d’Alpine. Le score publié par NVD et cve.org est de 8.1 (complexité d’attaque élevée). Red Hat retient un score préliminaire de 9.8. Ubuntu classe la faille en priorité haute.
GreyNoise a observé une première exploitation réussie le 7 novembre 2026, deux jours après la publication du correctif et d’un exploit public. Les sessions relevées enchaînent reconnaissance, lecture de /etc/shadow et création d’un compte server_manager doté d’une règle doas sans mot de passe.

Évaluer son exposition

Selon l’avis Alpine, une machine est exposée si toutes ces conditions sont réunies :
  • sshd vient du paquet openssh-server (compilé sans PAM), ou de openssh-server-pam avec UsePAM no ;
  • PasswordAuthentication vaut yes, la valeur par défaut d’OpenSSH ;
  • un compte a * comme champ de mot de passe : root dans l’image de base, un utilisateur qui ne se connecte que par clé, un utilisateur d’annuaire ;
  • au moins un autre compte local a un mot de passe haché en $5$ ou $6$.
L’attaquant doit connaître le nom du compte visé. root reste protégé par le réglage par défaut PermitRootLogin prohibit-password, sauf si un autre compte accessible peut devenir root, par exemple avec doas.
Les images tiny-cloud officielles (qcow2, VHD, AMI) livrent un utilisateur alpine sans mot de passe et autorisé à doas sans mot de passe. Elles sont sûres au premier démarrage, et deviennent exploitables dès qu’un mot de passe haché apparaît sur la machine, par exemple un mot de passe console défini par l’administrateur.

VPS Debian, Ubuntu, AlmaLinux : l’hôte n’est pas exposé

Ubuntu indique que son OpenSSH est lié à glibc et utilise PAM, donc non vulnérable, sur toutes ses versions. Red Hat déclare ses produits non affectés. Debian classe la faille « unimportant » pour son paquet et n’intègre le correctif qu’en unstable et forky. Le sshd de votre VPS n’appelle donc aucune action. Ce qu’il faut vérifier, ce sont les conteneurs Alpine qui tournent dessus.
Un conteneur qui répond par un numéro de version Alpine et qui fait tourner sshd relève de la section suivante. Même logique pour un pod Kubernetes construit sur une image Alpine qui lance sshd.

Mettre à jour Alpine Linux

Le correctif est la mise à jour du paquet openssh, suivie d’un redémarrage de sshd. La mise à jour seule ne remplace pas le démon déjà lancé. Les versions ponctuelles 3.21.10, 3.22.8, 3.23.8 et 3.24.4 intègrent le paquet corrigé. Alpine a aussi publié des paquets pour les branches qui ne reçoivent plus de mises à jour régulières, jusqu’à 3.16.

Conteneurs Docker

Si l’image est la vôtre, reconstruisez-la sur une version d’Alpine qui contient le correctif (3.21.10, 3.22.8, 3.23.8, 3.24.4 ou ultérieure), puis recréez le conteneur.
En attendant, vous pouvez corriger un conteneur en cours d’exécution :
Cette correction disparaît à la prochaine recréation du conteneur : seule la reconstruction de l’image est durable. Pour une image tierce, attendez la version corrigée de l’éditeur et appliquez la mitigation ci-dessous en attendant.

Mitigation en attendant le correctif

Alpine recommande de désactiver l’authentification par mot de passe. Avant de commencer, vérifiez que la connexion par clé SSH fonctionne et gardez votre session ouverte jusqu’à avoir testé une nouvelle connexion. À exécuter en root :
La commande sed modifie aussi les lignes situées dans un bloc Match.

Vérifier la mitigation

Attendu : passwordauthentication no. Après une mise à jour, comparez la sortie de apk list -I | grep openssh avec le tableau de votre branche.

Chercher des traces

Des exploitations sont constatées depuis le 7 novembre. Sur une machine Alpine exposée, cherchez des connexions par mot de passe sur des comptes qui n’en ont pas :
Une ligne Accepted password for sur l’un de ces comptes (root, alpine, un utilisateur à clé) signe une intrusion. Passez aussi en revue l’usage de doas, les comptes, fichiers et clés authorized_keys récents. Un compte server_manager que vous n’avez pas créé est un indicateur relevé par GreyNoise. Si vous ne pouvez pas exclure une connexion, traitez la machine comme compromise.

Annuler la mitigation

Une fois le paquet corrigé installé, si vous avez besoin des mots de passe :

Et après ?

La connexion par clé sans mot de passe reste la meilleure configuration pour un serveur exposé : gardez PasswordAuthentication no même après la mise à jour. Pour une autre faille OpenSSH récente, lisez regreSSHion (CVE-2024-6387). Pour toute question technique, ouvrez un ticket depuis votre espace client OnetSolutions.