Si vous utilisez la solution open source Keycloak, vous devez lire cet article avec attention. Une nouvelle faille de sécurité (CVE-2026-18963) permet à un attaquant non authentifié de réinitialiser le mot de passe de n’importe quel compte hébergé sur un serveur Keycloak vulnérable, puis d’en prendre le contrôle. Voici comment vous protéger.
Keycloak est une solution open source de gestion des identités et des accès (IAM) très répandue, aussi bien dans les infrastructures d’entreprise que dans les home labs. Elle permet de centraliser l’authentification de plusieurs applications derrière un même fournisseur d’identité. J’ai d’ailleurs publié un tutoriel d’installation de Keycloak avec Docker.
Autant dire qu’une faille permettant de s’emparer de n’importe quel compte sur un serveur Keycloak mérite une attention particulière. Et la mauvaise nouvelle, c’est exactement ce que permet la CVE-2026-18963, une faille divulguée le 18 août 2026 par Red Hat.
Le serveur croit que le lien reçu par e-mail a été cliqué
La vulnérabilité se situe dans le flux reset-credentials du composant keycloak-services, c’est-à-dire le mécanisme qui gère la procédure de mot de passe oublié. Comme l’explique Red Hat, il est possible de détourner cette fonctionnalité : “Le défaut permet à un attaquant non authentifié de forcer la procédure de réinitialisation de mot de passe pour n’importe quel utilisateur, sans avoir besoin de cliquer sur le lien de vérification par e-mail requis. Cela peut permettre à l’attaquant de prendre le contrôle total des comptes utilisateurs visés en définissant directement de nouvelles informations d’identification.” – Une vilaine faille.
Autrement dit, le serveur Keycloak considère l’étape de validation par e-mail comme validée alors qu’elle ne l’a jamais été… Ceci à cause d’un problème de sécurité dans le flux d’authentification. Cette vulnérabilité associée à un score CVSS de 9.1 sur 10 est exploitable à distance sans authentification. Et l’utilisateur n’a pas besoin d’interagir avec l’attaquant, ce dernier a seulement besoin d’avoir accès à l’interface de connexion de Keycloak : il peut tomber dessus par rebond si l’accès à une application passe par une authentification Keycloak.
Au-delà de l’accès à l’interface de Keycloak, il y a deux autres conditions à respecter :
L’attaquant doit connaître le nom d’un utilisateur à prendre pour cible,
La fonctionnalité de réinitialisation de mot de passe doit être activée pour que la faille soit exploitable.
C’est par l’intermédiaire de la société française Aduneo, spécialisée dans l’IAM, que j’ai fait la découverte de cette faille (via ce post LinkedIn). J’ai déjà parlé d’Aduneo lorsque j’ai évoqué l’outil open source ClientFedID. D’ailleurs, selon Aduneo, deux requêtes HTTP suffiraient à un attaquant connaissant un simple nom d’utilisateur pour aboutir à la prise de contrôle du compte, ce qui rend l’attaque scriptable et automatisable.
Ce correctif de sécurité a été intégré sur la branche actuelle de Keycloak, tout en étant rétroporté sur d’anciennes branches. Ainsi, voici les versions avec le patch :
Keycloak 26.7.2, publiée le 19 août 2026.
Keycloak 26.6.6.
Keycloak 26.4.15.
Toute version antérieure au sein de ces branches est à considérer comme vulnérable. Dans le cas où vous ne pouvez pas appliquer le patch pour le moment, il existe une mesure d’atténuation temporaire : désactiver la fonctionnalité de mot de passe oublié sur l’ensemble des realms.
Attention, cette méthode empêche que la vulnérabilité soit exploitée, mais elle prive aussi vos utilisateurs de la réinitialisation du mot de passe en libre-service.
Vérifier si votre instance a déjà été visée
À l’heure où j’écris cet article, aucune exploitation de cette faille dans la nature n’a été rapportée publiquement. Pour autant, je suis tombé sur un script de recherche de traces d’exploitation publié par la société suisse KYOS sur GitHub. Si certains d’entre vous veulent effectuer des vérifications, il peut s’avérer utile.
Ce script interroge la base du serveur Keycloak pour repérer :
Les mots de passe définis sur des comptes pendant la fenêtre d’exposition, via le champ credential.created_date.
Les réinitialisations abouties sans envoi d’e-mail préalable dans les 24 heures, ce qui est en quelque sorte la signature de cette attaque.
Les réinitialisations réalisées par l’API d’administration.
L’état de la journalisation des événements.
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.