CVE-2026-18963 : la faille Keycloak qui donnait n'importe quel compte.

En août 2026, une faille critique - score 9,1 sur 10 - a été rendue publique dans Keycloak, la solution open source de gestion des identités utilisée par un très grand nombre d'organisations pour centraliser les connexions à leurs applications. La faille, CVE-2026-18963, permettait à un inconnu, sans aucun compte, de prendre le contrôle de n'importe quel compte utilisateur. Pas de mot de passe deviné, pas d'hameçonnage : juste un défaut dans le processus lui-même.

Ce guide explique le mécanisme en partant de zéro, comment vérifier si vous avez été touché, et comment corriger. Il ne montre pas comment reproduire le contournement : la faille est corrigée depuis fin août 2026, et ce que vous avez besoin de savoir, c'est comment elle fonctionnait pour la comprendre, pas comment la déclencher.

1. Comment se passe une réinitialisation NORMALE

Imaginez l'entrée d'un établissement dont l'accès est contrôlé. Quand vous avez oublié votre mot de passe, le système vous envoie un e-mail avec un lien unique. Ce lien joue le rôle du videur qui vérifie votre identité par téléphone avant de vous laisser entrer : en cliquant, vous prouvez que vous avez accès à la boîte mail du compte. Sans cette vérification, n'importe qui pourrait réinitialiser le mot de passe de n'importe qui, simplement en connaissant son adresse e-mail.

Techniquement, ce clic déclenche une requête bien précise : GET /realms/<realm>/login-actions/action-token?key=.... Retenez cette adresse : son absence dans les journaux sera, plus loin, la preuve qu'un compte a été pris sans passer par cette porte.

2. Où se trouvait la faille

Le processus de réinitialisation de Keycloak avance par étapes : demander → recevoir l'e-mail → cliquer sur le lien → choisir un nouveau mot de passe. Deux défauts se combinaient :

• L'étape qui gère l'e-mail (ResetCredentialEmail) marquait le compte comme « e-mail vérifié » et laissait le processus continuer, sans jamais vérifier qu'un jeton d'action valide avait réellement été présenté. Le contrôle existait dans le code, mais son résultat n'était jamais consulté.
• L'état interne qui retient « à quelle étape on en est » n'était pas rattaché de façon stricte à l'exécution en cours du flux - une confusion d'identifiants (comparaison qui ne distinguait pas la casse) permettait de faire croire au système qu'une étape avait déjà été franchie.

Résultat : en pilotant l'ordre des requêtes du flux, on pouvait arriver directement à « choisissez un nouveau mot de passe » pour le compte de son choix, sans jamais avoir cliqué sur un lien reçu par e-mail.

C'est un cas d'école de la catégorie CWE-640 (« mécanisme de récupération de mot de passe faible »). La leçon dépasse Keycloak : un contrôle de sécurité qui existe dans le code mais dont le résultat n'est jamais vérifié équivaut à l'absence de contrôle.

3. Vérifier si vous êtes concerné

D'abord, la version. La faille touche Keycloak (amont) antérieur à 26.7.2, et la distribution Red Hat Build of Keycloak antérieure à 26.4.15 ou à 26.6.12 sur la branche 26.6. Dans la console d'administration, la version s'affiche en bas de la page d'accueil, ou via :

curl -s http://votre-serveur:8080/realms/master | grep -o '"[^"]*version[^"]*"'

Ensuite, une recherche de traces dans la base de données Keycloak (PostgreSQL ici - adaptez les noms de table si vous utilisez un autre moteur). Ces requêtes sont uniquement des lectures : elles ne modifient rien.

a. Comptes dont le mot de passe a changé depuis la divulgation (18 août 2026) :

SQL

SELECT user_id, created_date
FROM credential
WHERE type = 'password'
  AND created_date >= EXTRACT(EPOCH FROM TIMESTAMP '2026-08-18') * 1000
ORDER BY created_date;

C'est une liste de candidats - la plupart correspondent à de vraies réinitialisations volontaires. L'étape suivante affine.

b. Le signe le plus net : un compte « vérifié » sans qu'aucun événement ne l'explique. Un compte marqué email_verified mais pour lequel il n'existe aucun événement VERIFY_EMAIL ni UPDATE_EMAIL, et aucune action d'administrateur, n'a aucune explication innocente d'être dans cet état :

SQL

SELECT u.username, u.email_verified
FROM user_entity u
WHERE u.email_verified = true
  AND NOT EXISTS (
    SELECT 1 FROM event_entity e
    WHERE e.user_id = u.id
      AND e.type IN ('VERIFY_EMAIL', 'UPDATE_EMAIL')
  );

c. Croiser avec les journaux d'accès web. Pour chaque compte suspect, cherchez la requête action-token décrite plus haut, juste avant le changement de mot de passe. Son absence confirme que le mot de passe a changé sans passer par le lien e-mail.

4. Étapes de correction, dans l'ordre

Étape 1 - Planifier la mise à jour

Notez la version cible selon votre distribution :

• Keycloak amont (upstream, quay.io/keycloak/keycloak) : 26.7.2 ou plus récent.
• Red Hat Build of Keycloak, branche 26.4 : 26.4.15 ou plus récent.
• Red Hat Build of Keycloak, branche 26.6 : 26.6.12 ou plus récent.

Étape 2 - Sauvegarder avant de toucher à quoi que ce soit

pg_dump -U keycloak -Fc keycloak_db > sauvegarde_avant_maj.dump

Une mise à jour de composant d'authentification ne doit jamais se faire sans point de retour possible - c'est la porte d'entrée de toutes vos applications.

Étape 3 - Mettre à jour l'image

Si Keycloak tourne en conteneur, changez simplement le tag de version dans votre fichier de déploiement :

docker-compose.yml (extrait)

services:
  keycloak:
    image: quay.io/keycloak/keycloak:26.7.2
    command: start

Puis relancez :

docker compose pull keycloak
docker compose up -d keycloak

Sur Kubernetes, la même logique s'applique en changeant le tag d'image dans votre déploiement, suivi d'un kubectl rollout restart deployment/keycloak.

Étape 4 - Vérifier la version après redémarrage

docker logs keycloak 2>&1 | grep -i "keycloak.*started"

La ligne affichée doit mentionner le numéro de version cible. Contrôlez aussi dans la console d'administration, en bas de la page d'accueil du realm master.

Étape 5 - Si vous ne pouvez pas mettre à jour immédiatement

Il n'existe pas de configuration qui neutralise cette faille sans mise à jour : le défaut est dans le code du flux lui-même. La seule mesure de repli valable est de restreindre l'accès public au chemin /realms/*/login-actions/* via votre reverse proxy ou votre pare-feu applicatif, le temps de patcher - par exemple en le limitant aux adresses IP de vos utilisateurs connus, ou en ajoutant une limite de débit stricte. Ce n'est qu'une réduction temporaire du risque, pas une correction.

Étape 6 - Si vous trouvez des traces de compromission

• Forcez la réinitialisation des comptes concernés par un canal que vous maîtrisez (pas le flux public de réinitialisation, tant que vous n'avez pas patché).
• Invalidez toutes les sessions actives de ces comptes depuis la console d'administration (onglet « Sessions » de l'utilisateur).
• Vérifiez qu'aucune adresse e-mail de compte n'a été modifiée par l'attaquant pour garder un accès de secours - un changement d'e-mail est un signe fort de persistance.

Sources

• Red Hat - fiche CVE-2026-18963
• Dépôt Keycloak - avis de sécurité (issue #51833)
• Keycloak - documentation d'administration
• Kenawek - Vous n'avez pas d'inventaire, vous avez une intuition
• Kenawek - MFA : pourquoi l'authentification multifacteur n'est plus optionnelle