La réinitialisation de mot de passe Keycloak vient d’attirer l’attention de la communauté sécurité. Red Hat et le projet Keycloak ont publié des correctifs pour une faille critique affectant le serveur open-source de gestion d’identité et d’accès. Selon les avis publiés, elle pourrait permettre à un attaquant non authentifié de prendre le contrôle de n’importe quel compte en déclenchant une procédure de changement de mot de passe.
Le défaut a reçu l’identifiant CVE-2026-18963 et une note de 9,1 sur l’échelle CVSS, Red Hat agissant en tant que CNA (CVE Numbering Authority). La cause racine est liée à une validation d’état inappropriée dans le flux d’authentification de réinitialisation des informations d’identification.
Si vous utilisez Keycloak en amont ou une version packagée par Red Hat, il est essentiel d’appliquer les mises à jour disponibles et, le cas échéant, de mettre en œuvre une atténuation temporaire.
Pourquoi la réinitialisation de mot de passe Keycloak est un risque critique
Le scénario décrit par Red Hat repose sur le fonctionnement du flux que Keycloak exécute lorsqu’un utilisateur demande un mot de passe oublié. En situation normale, le système s’appuie sur un processus cohérent d’état et sur un jeton (token) transmis par email pour autoriser l’étape de mise à jour du mot de passe.
D’après les éléments fournis, l’attaquant peut contourner cette logique. Il envoie une requête spécialement construite vers l’endpoint reset-credentials (réinitialisation des identifiants). À la suite de cette requête, la session d’authentification bascule directement vers la phase de modification du mot de passe, sans exiger l’action token normalement envoyée à l’utilisateur.
Résultat : une exploitation réussie peut conduire à une
Référence CVE-2026-18963 : sévérité et classification
La vulnérabilité est classée comme un mécanisme faible de récupération de mots de passe pour utilisateur ayant oublié son mot de passe (catégorie CWE-640). La sévérité a été qualifiée de Critical car un attaquant distant non authentifié pourrait exploiter le problème sans interaction utilisateur.
Au moment de la publication des informations, aucun indice d’exploitation n’était rapporté. Il n’existait pas non plus, selon les sources consultées, de preuve d’un exploit public vérifié au 24 août 2026.
Versions à mettre à jour : amont Keycloak et build Red Hat
Les recommandations de mise à jour diffèrent selon que vous utilisez Keycloak “upstream” (la distribution du projet) ou une version issue de Red Hat build de Keycloak.
Keycloak upstream
Les utilisateurs de Keycloak en amont sont invités à passer à la version 26.7.2, sortie le 19 août 2026.
Red Hat build of Keycloak (RHBK)
Pour les clients utilisant Red Hat build of Keycloak, Red Hat indique des correctifs publiés sous la forme de mises à jour associées à des versions spécifiques, notamment :
- Pour le stream 26.4 : mises à jour correspondant à 26.4.15
- Pour le stream 26.6 : mises à jour correspondant à 26.6.6
En parallèle, Red Hat précise des éléments de “non-impact” sur certaines variantes de bundles et images conteneurs, notamment des ensembles d’opérateurs et images associées à 26.4.15-1 et 26.6.6-1, ainsi que des images rhbk/keycloak-rhel9 et leurs déclinaisons opérateur.
Le message central reste toutefois le même : appliquez les mises à jour fournies par Red Hat pour votre stream, ou basculez vers une version corrigée.
Mitigation temporaire en attendant la mise à jour
Si le déploiement des correctifs n’est pas possible immédiatement, Red Hat propose une atténuation temporaire. Elle consiste à désactiver la fonctionnalité “Mot de passe oublié” dans l’ensemble des realms.
Dans la console d’administration RHBK, l’option se trouve dans :
Realm settings > Login > Forgot password
Red Hat souligne que le réglage doit être appliqué à chaque realm. L’organisation recommande également de mettre à niveau vers une version corrigée dès que possible, car cette mitigation ne remplace pas le correctif.
Où se situe la faille dans le flux de récupération
Le rapport de bug mentionne un problème de gestion d’état du flux. Concrètement, la vulnérabilité ne se résume pas à un simple “mot de passe faible” : elle touche la mécanique qui garantit que l’étape de changement de mot de passe intervient au bon moment et dans les conditions prévues.
En pratique, l’attaque décrite exploite une faiblesse de validation : le système passe directement à la mise à jour du mot de passe alors que, normalement, un élément de contrôle (le token issu du canal email) devrait être requis.
À noter : les sources publiées ne précisent pas si un correctif élimine totalement le problème dans tous les cas d’usage. Elles n’indiquent pas non plus si toutes les configurations activant la récupération “forgot password” sont exploitées de la même façon, ou seulement certaines variantes du flux de réinitialisation.
Impact potentiel au-delà de Keycloak
En dehors du détail technique de CVE-2026-18963, des chercheurs rappellent que les systèmes d’identité jouent souvent un rôle structurant dans les environnements d’entreprise.
Un chercheur, Enzo Mongin, a notamment commenté un autre problème de contrôle d’accès publié en juillet. Son propos met en évidence une idée : lorsqu’un attaquant franchit une frontière liée à l’accès, il peut ensuite s’étendre à tout ce qui se trouve derrière le système d’identité. Autrement dit, une prise de contrôle d’un compte Keycloak peut avoir des répercussions sur les applications et services raccordés.
Contexte : autres CVE corrigées dans la même fenêtre
La version 26.7.2 ne corrige pas uniquement CVE-2026-18963. D’après les notes de version, elle inclut aussi la correction de cinq autres identifiants (au total, CVE-2026-18963 fait partie d’un ensemble de CVE corrigées). La même publication adresse par exemple CVE-2026-15571, liée à une valeur de hachage prévisible qui pourrait faciliter une prise de contrôle via un client malveillant utilisant OpenID Connect (OIDC).
Deux semaines plus tôt, une autre sortie (Keycloak 26.7.1) avait déjà introduit des correctifs pour une série plus large de vulnérabilités, dont des sujets liés à des scénarios d’authentification SAML et à des politiques de registration dynamique des clients, ainsi qu’à des risques liés à la falsification de rôles via des mappages liés aux propriétés utilisateur.
Par ailleurs, un post publié par Univention indiquait que Nubus n’était pas concerné par ce problème, car la fonctionnalité “forgot password” n’était pas activée dans ses déploiements Keycloak. Cette précision reste toutefois spécifique aux configurations évoquées.
Ce que vous devez faire maintenant
Pour réduire le risque lié à la réinitialisation de mot de passe Keycloak, la priorité est claire :
- Mettre à jour vers la version corrigée correspondant à votre déploiement (Keycloak upstream 26.7.2 ou stream Red Hat build de Keycloak avec les correctifs indiqués).
- Si la mise à jour immédiate n’est pas possible, désactiver “Forgot password” sur tous les realms jusqu’à l’application complète des correctifs.
- Vérifier vos pratiques de déploiement (containers, opérateurs, bundles) afin que les correctifs correspondent bien aux composants réellement utilisés.
Même en l’absence d’exploitation confirmée à la date mentionnée, la combinaison “attaque à distance”, “aucune authentification” et “prise de contrôle” justifie une réponse rapide.
Conclusion
La faille identifiée sous CVE-2026-18963 rappelle que le mécanisme de réinitialisation de mot de passe Keycloak n’est pas un simple confort pour l’utilisateur : c’est un flux critique qui doit rester strictement contrôlé. Grâce aux correctifs publiés, vous pouvez supprimer le défaut de validation d’état décrit par Red Hat, mais il faut agir dès maintenant — et, en attendant, désactiver la fonctionnalité “mot de passe oublié” si nécessaire.
Source: https://thehackernews.com/2026/08/critical-keycloak-password-reset-flaw.html
