Keycloak : un compte admin pris sans mot de passe

Ce qui se passe

Red Hat et le projet Keycloak ont publié des correctifs pour CVE-2026-18963, une faille du serveur d'identité open source notée 9,1 sur 10. Elle permet à un attaquant distant, sans compte ni interaction de la victime, de reprendre n'importe quel compte utilisateur — y compris un compte administrateur.

Le défaut se trouve dans le parcours reset-credentials, celui que Keycloak déroule quand quelqu'un déclare avoir oublié son mot de passe. Red Hat le classe en CWE-640, « mécanisme de récupération de mot de passe faible », et pointe une mauvaise validation de l'état de la session d'authentification.

Le mécanisme, en trois temps

Le parcours normal ressemble à ceci : demande de réinitialisation, envoi d'un jeton d'action par courriel, vérification de ce jeton, puis saisie du nouveau mot de passe. Chaque étape n'est censée être atteignable qu'après la précédente.

Avec une requête spécialement construite vers le point d'entrée de réinitialisation, la session bascule directement à l'étape de mise à jour du mot de passe. Le jeton envoyé par courriel n'est jamais exigé. L'attaquant choisit le compte visé, pose un nouveau mot de passe, et se connecte.

Le chercheur d'Escape à l'origine du signalement décrit une exploitation immédiate une fois la mécanique comprise : il n'y a ni condition de course, ni prérequis d'accès réseau particulier.

Pourquoi ça compte

Keycloak est rarement une application parmi d'autres : c'est la brique posée devant les autres. Une prise de contrôle d'un compte administrateur ne s'arrête pas au serveur d'identité, elle donne accès aux clients configurés, aux rôles, et à la fabrication de jetons pour les applications qui font confiance à ce serveur.

Deux éléments jouent contre vous à partir de maintenant :

Le correctif étant public, la comparaison entre les deux versions expose la logique du défaut. C'est le scénario classique du délai entre publication et exploitation.
L'attaque ne laisse aucune trace côté utilisateur : pas de courriel, pas de validation à approuver, rien à cliquer.

À la date de publication de l'avis, aucune exploitation n'avait été observée et aucun code d'attaque public n'avait été retrouvé.

Comment s'y prendre

Mettre à jour. Keycloak amont : version 26.7.2, publiée le 19 août
1. Version Red Hat (RHBK) : 26.4.15 ou 26.6.6.
Chercher les traces côté serveur. Le signal utile est une réinitialisation aboutie sans envoi de courriel correspondant, ou une mise à jour de mot de passe dont l'horodatage ne correspond à aucune demande légitime.
Vérifier les comptes à privilèges : mots de passe changés récemment, sessions actives inconnues, nouveaux clients ou rôles créés dans la foulée.
Si la mise à jour doit attendre, restreindre l'accès réseau au point d'entrée de réinitialisation le temps du correctif.

À retenir

Le bug n'est pas cryptographique, il est logique : une machine à états qui accepte qu'on saute une étape. C'est le type de défaut qu'aucune revue de dépendances ne détecte, et que seule la mise à jour corrige.

Source : The Hacker News