sshole (CVE-2026-123158) : La faille OpenSSH qui frappe Alpine Linux et comment la corriger

Par Eoin Villarin, 2026-11-07

- Une faille OpenSSH appelée sshole permet aux attaquants de se connecter à des comptes sans mot de passe sur Alpine Linux et d'autres systèmes basés sur musl, et elle est déjà exploitée. Qui est affecté, comment vérifier vos serveurs et comment la corriger.

Une faille récemment divulguée dans OpenSSH appelée sshole, suivie sous le nom de CVE-2026-123158, permet aux attaquants de se connecter à certains comptes Linux qui ne sont pas censés accepter de mots de passe du tout. Elle affecte OpenSSH sur les systèmes basés sur musl tels qu'Alpine Linux, elle a été corrigée le 5 novembre 2026, et les attaquants ont commencé à l'utiliser moins de neuf heures après sa publication. Si vous exécutez des serveurs Alpine, des images Docker basées sur Alpine avec SSH, ou des petits appareils sur OpenWrt, vérifiez-les aujourd'hui.

Quelle est la faille sshole d’OpenSSH ?

Sur les systèmes basés sur musl, la fonction crypt() de la bibliothèque C renvoie un astérisque unique (*) lorsqu’elle ne parvient pas à hacher un mot de passe, par exemple lorsque le mot de passe dépasse la limite de 256 octets. De nombreux systèmes Linux utilisent également un * unique dans le champ du mot de passe pour signifier « ce compte n’a pas de mot de passe ». OpenSSH a comparé les deux, a vu le *, et l’a considéré comme une correspondance. L’envoi d’un mot de passe surdimensionné suffisait à se connecter à un compte sans mot de passe.

Le comportement remonte à un changement de 2016 dans la gestion des mots de passe d’OpenSSH. Le chercheur en sécurité Özgün Kültekin l’a découvert à l’aide d’agents IA qui ont exécuté environ 17 600 tests d’authentification. La CVE possède un score CVSS 3.1 de 8,1, classé élevé, et la correction a été livrée dans OpenSSH 10.6p2.

Suis-je affecté ?

Un serveur est à risque lorsque toutes ces conditions sont vraies :

• Il exécute OpenSSH antérieur à 10.6p2 sur un système basé sur musl, tel qu’Alpine Linux, OpenWrt, Buildroot ou Yocto.
• sshd n'utilise pas PAM. Ceci est la valeur par défaut pour le paquet openssh-server d'Alpine.
• Les connexions SSH par mot de passe sont activées, ce qui est le comportement par défaut d’OpenSSH.
• Au moins un compte a uniquement * dans son champ de mot de passe, tel qu'un utilisateur à clé uniquement, à côté d'un autre compte avec un hachage de mot de passe réel.

Les images cloud officielles AWS et Azure d'Alpine de la 3.18.11 à la 3.24.3 constituent un cas grave : elles incluent un utilisateur alpine par défaut sans mot de passe et avec un doas sans mot de passe, ce qui signifie qu'une connexion réussie peut devenir root.

Non concerné : systèmes basés sur glibc tels que Debian, Ubuntu et Fedora, configurations qui vérifient les mots de passe via PAM, Dropbear et OpenBSD. Les comptes avec un hachage de mot de passe réel ne peuvent pas être contournés de cette façon.

Comment vérifier vos serveurs

Exécutez ces commandes en tant que root sur chaque serveur ou conteneur Alpine exécutant sshd :

1. Vérifiez les paramètres SSH : sshd -T | grep -i -E 'passwordauthentication|usepam'. Si l'authentification par mot de passe est désactivée ou si PAM est activé, cette faille ne peut pas être utilisée.
2. Vérifiez le package installé : apk list --installed | grep openssh, et comparez-le avec les versions corrigées ci-dessous.
3. Lister les comptes sans mot de passe : awk -F: '$2=="*" {print $1}' /etc/shadow.
4. Recherchez les connexions à ces comptes : grep "Accepted password" /var/log/messages. Une connexion de mot de passe à un compte avec * dans son champ de mot de passe signifie que le serveur a probablement été attaqué.

Comment corriger la CVE‑2026‑123158 sur Alpine Linux

Alpine a expédié des packages corrigés pour chaque branche de la 3.16 à edge le même jour que la divulgation. Mettez à jour et redémarrez sshd, car l'installation de la mise à jour ne redémarre pas le processus en cours :

apk upgrade -U -a et ensuite rc-service sshd restart

Pour Docker, reconstruisez chaque image contenant OpenSSH à partir d’une image de base fraîche et redéployez‑la. Notez que certaines images SSH sur Docker Hub, telles que openssh‑server de linuxserver, désactivent par défaut les connexions par mot de passe mais deviennent exposées lorsque PASSWORD_ACCESS=true est défini.

Les versions d'Alpine antérieures à la 3.16 ne reçoivent pas de package corrigé. Mettez-les à niveau vers une version prise en charge ou utilisez la solution de contournement ci-dessous.

Solution rapide : désactivez les connexions SSH par mot de passe

Si vous ne pouvez pas mettre à jour immédiatement, définissez PasswordAuthentication no dans /etc/ssh/sshd_config, redémarrez sshd et exécutez à nouveau la vérification sshd -T. Assurez-vous que votre connexion avec une clé SSH fonctionne avant de faire cela, sinon vous pouvez vous exclure. La connexion SSH avec une clé uniquement est un bon paramètre par défaut pour tout serveur de toute façon.

Que faire si vous pensez avoir été touché

• Passez en revue l’utilisation de doas, les utilisateurs créés récemment et chaque fichier authorized_keys.
• Vérifiez les processus inconnus, les travaux cron et les connexions sortantes.
• Si vous ne pouvez pas exclure une compromission, considérez le serveur comme compromis : reconstruisez‑le à partir d’une image propre et faites pivoter chaque mot de passe, clé et jeton qu’il détenait.
• Ne téléchargez pas d'exploits proof‑of‑concept depuis GitHub pour tester vos serveurs. Les chercheurs avertissent que certains ne sont pas vérifiés et peuvent contenir des logiciels malveillants.

Maintenir les serveurs à jour représente une grande partie du maintenance du site Web Je le fais pour les clients. Si vous avez besoin d’aide pour vérifier votre hébergement, votre configuration Docker ou SSH, me contacter.

Foire aux questions

Ubuntu ou Debian sont-ils affectés par sshole ?

Non. Debian, Ubuntu, Fedora et autres systèmes basés sur glibc ne sont pas affectés, ainsi que les configurations qui utilisent PAM pour les vérifications de mot de passe.

La SSH sans clé me protège-t-elle ?

Oui. Avec PasswordAuthentication défini sur non, le serveur n'accepte pas les mots de passe, de sorte que la faille ne peut pas être utilisée.

Le CVE-2026-123158 est-il exploité ?

Oui. La société de renseignement sur les menaces Previdian a vu la première tentative moins de neuf heures après la publication du CVE, et un attaquant a obtenu les privilèges root sur l'un de ses honeypots exécutant Alpine Linux.

Quelle version d'OpenSSH la corrige ?

OpenSSH 10.6p2. Sur Alpine, installez le package openssh corrigé pour votre branche et redémarrez sshd.

Les conteneurs Docker sont-ils affectés ?

Les conteneurs basés sur Alpine qui exécutent sshd avec les connexions par mot de passe activées peuvent être affectés. Reconstruisez-les à partir d'une image de base mise à jour et redéployez-les.

Dois-je redémarrer après la mise à jour ?

Oui. Le sshd en cours d'exécution conserve le code vulnérable en mémoire jusqu'à ce que vous redémarriez le service.

Sources

• BleepingComputer : La faille OpenSSH permet aux attaquants de se connecter aux comptes Linux désactivés pour les mots de passe
• Help Net Security : faille OpenSSH exploitée dans le wild quelques heures après sa divulgation
• Cycode : contournement du mot de passe sshole OpenSSH sur Alpine Linux
• Orca Security : contournement d’authentification sshole sur Alpine Linux