CVE-2026-18963 : deux requêtes HTTP suffisent pour prendre le contrôle de n'importe quel compte Keycloak

Rapport CTI technique du 27 août 2026

Résumé exécutif

Une faille d'authentification affecte le flux reset-credentials du composant keycloak-services, moteur central de gestion des identités du Red Hat Build of Keycloak. Référencée CVE-2026-18963 et notée 9.1 sur l'échelle CVSS, elle permet à un attaquant non authentifié de finaliser une réinitialisation de mot de passe sans jamais cliquer sur le lien de vérification envoyé par email. En clair, l'attaquant devient indiscernable du titulaire légitime du compte dès que le reset aboutit, sur n'importe quel compte dont il connaît le nom d'utilisateur, y compris un compte administrateur.

Selon le cabinet Aduneo, deux requêtes HTTP bien construites suffisent à faire aboutir l'attaque, ce qui la rend triviale à scripter et à automatiser à grande échelle contre un annuaire d'identifiants connus. Red Hat a publié quatre advisories (RHSA-2026:56519, 56520, 56523 et 56524) et livré des versions corrigées de Keycloak le 19 août. Aucun exploit public vérifié n'a été recensé au moment de la rédaction, mais la simplicité de la chaîne d'exploitation réduit fortement l'intérêt de cette absence comme facteur de protection.

Chronologie

Date	Événement
2026-08-18	CVE-2026-18963 publiée au NVD, faille identifiée dans le flux reset-credentials de keycloak-services
2026-08-19	Sortie des versions corrigées Keycloak 26.7.2, 26.6.6 et 26.4.15
2026-08-20	Publication des advisories Red Hat RHSA-2026:56519 à RHSA-2026:56524, mise à jour de la fiche NVD
2026-08-21	Analyse technique détaillée publiée par SentinelOne, reprise par The Hacker News
2026-08-25	Alerte de sensibilisation relayée par le CERT thaïlandais (ThaiCERT) à destination des administrateurs Keycloak

Fiche vulnérabilité

CVE-2026-18963 | CVSS 9.1 (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N) | keycloak-services, flux reset-credentials (Red Hat Build of Keycloak)

La faille est classée CWE-640, mécanisme de récupération de mot de passe faible. Le flux normal de réinitialisation repose sur un jeton d'action signé, envoyé par email, que l'utilisateur doit ouvrir pour prouver qu'il possède bien l'adresse associée au compte. Le défaut se situe dans l'ordonnancement des étapes du graphe d'exécution : le service fait confiance à l'état de session intermédiaire et autorise la finalisation du changement de mot de passe sans vérifier que l'étape verify-email (ou son équivalent par jeton d'action) a réellement été consommée.

Conditions d'exploitation : aucune authentification préalable, aucun identifiant, aucune interaction de la victime. La fonctionnalité "Forgot password" doit être activée sur le realm ciblé, ce qui est le cas par défaut dans de nombreux déploiements. L'attaquant a seulement besoin de connaître ou de deviner un nom d'utilisateur ou une adresse email valide, puis d'initier le flux et de manipuler la séquence pour atteindre directement l'étape de définition du nouveau mot de passe, en contournant la validation du jeton envoyé par email.

PoC disponible : non, aucun code d'exploitation public vérifié n'a été recensé à ce jour. Patch disponible : oui, via les versions Keycloak 26.7.2, 26.6.6 et 26.4.15, ou les advisories Red Hat RHSA-2026:56519, RHSA-2026:56520, RHSA-2026:56523 et RHSA-2026:56524. Une mitigation de contournement existe pour les environnements ne pouvant pas patcher immédiatement : désactiver le flux reset-credentials au niveau du realm.

Diagramme de la chaîne d'attaque

Diagramme de la chaîne d'attaque disponible dans les visuels archivés de cet article.

Analyse technique

Étape 1 : reconnaissance du nom d'utilisateur cible

L'attaquant identifie un identifiant ou une adresse email valide sur le realm Keycloak visé. Cette étape ne demande aucun accès privilégié : énumération d'annuaire, fuite d'identifiants sur un dépôt public, ou simple ciblage d'un compte administrateur dont le nom suit une convention prévisible (admin@domaine, service-account, etc.).

Étape 2 : initiation du flux reset-credentials

L'attaquant soumet une requête vers l'endpoint /realms/{realm}/login-actions/reset-credentials avec le nom d'utilisateur ciblé. En fonctionnement normal, Keycloak génère un jeton d'action signé et l'envoie par email, bloquant toute progression tant que ce jeton n'est pas consommé via le lien reçu.

Étape 3 : contournement de la validation du jeton d'action

C'est ici que réside le défaut. Le graphe d'exécution du flux reset-credentials ne vérifie pas de façon stricte que l'étape verify-email a bien été franchie avant d'autoriser la suite. En manipulant l'état de session intermédiaire (les deux requêtes HTTP mentionnées par Aduneo), l'attaquant fait progresser le flux jusqu'à l'étape de définition du nouveau mot de passe sans avoir jamais eu accès à la boîte email de la victime.

Étape 4 : finalisation du changement de mot de passe

Le nouveau mot de passe soumis par l'attaquant est accepté et appliqué au compte cible. Aucune notification supplémentaire n'interrompt le processus côté serveur au-delà des logs d'événements standards. L'attaquant dispose désormais d'un jeu d'identifiants valides pour le compte visé.

Étape 5 : prise de contrôle et persistance

Avec le nouveau mot de passe, l'attaquant s'authentifie normalement sur les applications fédérées via ce realm Keycloak. Si le compte ciblé dispose de rôles élevés (administration du realm, accès à des applications tierces via SSO), l'accès obtenu dépasse largement le périmètre d'un compte utilisateur classique.

Indicateurs de compromission

Type	Valeur
Événement Keycloak suspect	UPDATE_PASSWORD réussi sans événement VERIFY_EMAIL ou EXECUTE_ACTION_TOKEN précédent dans la même session
Activité anormale	Multiples initiations RESET_PASSWORD contre des comptes distincts depuis une même IP ou un même client sur une courte fenêtre
Trace applicative	Complétion du flux reset-credentials sans consommation de jeton email visible dans les traces keycloak-services

Aucun indicateur réseau ou hash de malware n'est publié pour cette vulnérabilité : l'exploitation ne dépose aucun artefact binaire, elle abuse uniquement de la logique métier du flux d'authentification.

MITRE ATT&CK

Aucune cartographie officielle éditeur n'accompagne cette CVE. Le tableau suivant est une lecture technique construite à partir du mécanisme d'exploitation documenté, pas une attribution vendeur.

Tactique	Technique	ID	Justification
Initial Access	Exploit Public-Facing Application	T1190	L'endpoint reset-credentials est exposé publiquement et directement ciblé sans authentification préalable
Credential Access	Modify Authentication Process	T1556	L'attaquant interfère avec la logique du mécanisme de récupération de mot de passe pour en détourner le résultat
Persistence	Account Manipulation	T1098	Le nouveau mot de passe défini par l'attaquant constitue un identifiant valide et durable sur le compte compromis
Impact	Account Access Removal	T1531	Le titulaire légitime perd l'accès à son propre compte dès que le mot de passe est modifié à son insu

Remédiation : checklist opérationnelle

Mettre à jour immédiatement vers Keycloak 26.7.2, 26.6.6 ou 26.4.15, ou appliquer les advisories Red Hat RHSA-2026:56519 à RHSA-2026:56524 selon le canal de déploiement.
Si une mise à jour immédiate est impossible, désactiver le flux "Forgot password" sur tous les realms exposés : kcadm.sh update realms/REALM -s resetPasswordAllowed=false.
Auditer les logs d'événements realm depuis le 18 août à la recherche d'UPDATE_PASSWORD non précédés d'un jeton d'action consommé, en particulier sur les comptes à privilèges.
Forcer une réinitialisation de mot de passe et une révocation de session pour les comptes administrateurs et comptes de service, après application du correctif.
Restreindre l'exposition réseau des endpoints /realms/{realm}/login-actions/reset-credentials aux plages de confiance, ou les placer derrière un WAF avec limitation de débit.
Imposer le MFA sur l'ensemble des comptes pour qu'un mot de passe seul, même volé via ce vecteur, ne suffise pas à accéder aux applications en aval.
Centraliser les logs realm et admin events de Keycloak vers le SIEM pour corréler les resets de mot de passe avec les changements de comportement d'authentification (nouvel appareil, nouvelle géolocalisation, ré-enrôlement MFA).