*sshole : sur Alpine Linux, un mot de passe trop long peut mener à un accès root via SSH

*Un mot de passe de 300 caractères, et un compte censé refuser tout mot de passe vous laisse entrer. C'est le principe de la faille sshole, présente dans OpenSSH sur les systèmes musl depuis 2016. Voici ce qu'il faut savoir à propos de cette vulnérabilité.

Le 5 novembre 2026, le chercheur Özgün Kültekin a dévoilé une vulnérabilité découverte dans OpenSSH qui touche les systèmes Linux basés sur la bibliothèque C musl : Alpine Linux notamment, mais aussi les systèmes construits avec musl via OpenWrt, Buildroot ou Yocto. Associée à la référence CVE-2026-123158, elle a un score CVSS 3.1 de 8,1 sur 10.

Avant de parler de la vulnérabilité, commençons par un rappel. Sous Linux, on interdit la connexion par mot de passe à un compte utilisateur en remplaçant son empreinte par un astérisque dans le fichier /etc/shadow. En effectuant cette modification, aucune empreinte ne peut correspondre à *, donc aucun mot de passe n'est censé fonctionner.

Sauf que, sur un système musl, ce verrou saute avec un mot de passe trop long : selon le chercheur, n'importe quel mot de passe de 257 à 1 024 caractères est accepté. Oui, n'importe lequel.

Un système musl est une distribution Linux dont la bibliothèque C standard (la libc) est musl, et non glibc. Elle est plus légère et plus simple, ce qui explique notamment qu'elle soit utilisée par Alpine Linux. Les distributions comme Debian, Ubuntu ou encore Fedora utilisent glibc.

Un astérisque qui en rencontre un autre

La faille naît de deux choix faits séparément. Côté musl, depuis 2012, la fonction crypt() ne renvoie plus NULL en cas d'échec, mais une chaîne impossible à faire correspondre... à savoir un... astérisque ! Côté OpenSSH, en 2016, pour corriger la CVE-2016-6210 (énumération des utilisateurs par mesure du temps de réponse), sshd s'est mis à calculer une empreinte même pour les comptes sans empreinte exploitable, en empruntant le sel d'un autre compte.

Voici ce qu'il se passe : avec un mot de passe trop long, crypt() échoue et renvoie un astérisque, que sshd compare à celui stocké dans /etc/shadow. Les deux sont identiques, la connexion est acceptée.

Pour exploiter cette vulnérabilité, plusieurs conditions doivent être réunies :

• Système musl sans PAM : c'est le cas par défaut avec le paquet openssh-server d'Alpine Linux, ou avec UsePAM no.

• Authentification par mot de passe active : le réglage par défaut.

• Un compte dont l'empreinte est un astérisque : root, utilisateur par clé, compte d'annuaire... Les comptes verrouillés avec un point d'exclamation ne sont pas concernés.

• Un autre compte local avec un vrai mot de passe (empreinte SHA-256 ou SHA-512) : c'est lui qui fournit le sel.

Le scénario le plus à risque concerne les images cloud officielles d'Alpine Linux (AWS, Azure), de la 3.18.11 à la 3.24.3. Leur compte alpine n'a pas de mot de passe, mais il peut passer root avec doas (l’équivalent de sudo) sans en saisir un. Il devient exploitable dès qu’un mot de passe est défini sur la machine, et l’attaquant obtient alors un accès root. Au niveau du service SSH en lui-même, le compte root reste protégé par PermitRootLogin prohibit-password, sauf si l'option est positionnée sur yes (mauvaise pratique).

Mettez à jour OpenSSH et vérifiez vos journaux

OpenSSH 10.6p2, publiée le 5 novembre 2026, intègre un correctif de sécurité : "Nous considérons que la cause profonde de ce bug se situe en dehors de sshd, mais il est exploitable via sshd et peut y être évité.", précise l'équipe d'OpenSSH.

Le même jour, Alpine Linux a publié un avis de sécurité avec des correctifs pour toutes ses branches, de la 3.16 à edge (la branche de développement). Les branches stables reçoivent un correctif rétroporté (par exemple openssh 10.3_p1-r2 pour la 3.24). Vous devez donc mettre à jour votre système ! Alpine Linux est très utilisé dans les images Docker, mais si votre conteneur n'a pas d'accès SSH, il n'est pas affecté. C'est tout de même rare, un conteneur avec un accès SSH....

Si vous ne pouvez pas patcher, il reste une solution : désactiver l'authentification par mot de passe (PasswordAuthentication no), après avoir validé la connexion par clé SSH. Mon tutoriel sur la configuration de l'accès SSH avec une authentification par clé sous Proxmox VE détaille une démarche transposable.

Dans le cas où vous souhaitez vérifier rapidement votre serveur, Alpine recommande de rechercher dans /var/log/messages les connexions acceptées par mot de passe sur un compte qui n'en a pas (alpine, root, utilisateur par clé). La commande grep "Accepted password" /var/log/messages vous aidera.

Retrouvez plus d'informations sur le site sshhole.com.

Ajouter IT-Connect à mes
sources préférées

Cofondateur d'IT-Connect et Microsoft MVP "Cloud and Datacenter Management". Mon obsession depuis près de 15 ans ? Rendre l'administration système et la cybersécurité accessibles, que vous soyez junior ou confirmé. Plus qu'un métier, l'IT est pour moi une véritable passion. J’accompagne au quotidien les sysadmins et les professionnels de l’IT dans leur montée en compétences et leur veille technique.