CVE-2026-18963 : chasse aux traces d'exploitation de prise de contrôle de compte Keycloak

Un script psql qui recherche dans une base de données PostgreSQL Keycloak des traces d'exploitation de la CVE-2026-18963 (prise de contrôle de compte non authentifiée via le flux reset-credentials).

Publié par KYOS. Nous l'avons écrit en corrigeant les déploiements Keycloak que nous exploitons, pour vérifier qu'aucun compte n'avait été compromis pendant la fenêtre d'exposition.

La vulnérabilité

CVE-2026-18963 est une faille dans le flux reset-credentials de keycloak-services (keycloak#51833). Un attaquant non authentifié peut mener à bien le processus de réinitialisation de mot de passe pour n'importe quel utilisateur sans cliquer sur le lien de vérification par e-mail, puis définir un nouveau mot de passe sur le compte. Aucune interaction de l'utilisateur n'est requise.

Sévérité : critique, CVSS v3.1 9.1 (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N), selon Red Hat et NVD. La cause racine est une validation d'état inadéquate dans le flux d'authentification, corrigée dans keycloak#51844.

Versions affectées / corrigées

Tout ce qui est en dessous de ces versions dans les streams pris en charge est vulnérable. Les versions hors support (26.5.x, 26.3 et antérieures) ne reçoivent aucun correctif : considérez qu'elles sont exposées et mettez à niveau vers un stream corrigé. Red Hat liste l'ancien RH-SSO 7 comme non affecté ; le Red Hat Build de Keycloak 26.4/26.6 est corrigé dans 26.4.15-1 / 26.6.6-1.

Solution de contournement si vous ne pouvez pas appliquer le correctif immédiatement

Désactiver la réinitialisation de mot de passe en libre-service supprime le point d'entrée vulnérable : Admin console > Realm settings > Login > « Forgot password » désactivé, pour chaque realm. Via l'API d'administration : PUT /admin/realms/{realm} avec {"resetPasswordAllowed": false}.

Cela bloque le point de terminaison login-actions/reset-credentials mais empêche également les utilisateurs légitimes de réinitialiser leur propre mot de passe, considérez donc cela comme une mesure provisoire jusqu'à la mise à niveau. Notez que Red Hat ne répertorie aucune atténuation officielle pour cette CVE ; l'application du correctif est la seule vraie solution.

Ce que le script vérifie

cve-2026-18963-keycloak-hunt.sql exécute quatre requêtes en lecture seule :

Utilisation

# defaults: realm 'master', window since 2026-06-01
psql -U keycloak -d keycloak -f cve-2026-18963-keycloak-hunt.sql

# explicit realm and window (run once per realm, quote values exactly like this)
psql -U keycloak -d keycloak \
  -v realm="'myrealm'" -v since="'2026-05-01'" \
  -f cve-2026-18963-keycloak-hunt.sql

Définissez since juste avant que votre version vulnérable ne soit mise en service. Sur Kubernetes :

kubectl exec -it my-postgres-pod -- \
  psql -U keycloak -d keycloak -v realm="'myrealm'" -v since="'2026-05-01'" \
  -f - < cve-2026-18963-keycloak-hunt.sql

Interprétation des résultats

Les lignes de Q1 ne sont pas automatiquement des compromissions. Faites correspondre chacune à une cause légitime connue (réinitialisation en libre-service, action du support, nouvel enrôlement) et traitez tout élément inexpliqué comme un candidat à la prise de contrôle.

Les lignes de Q2 avec no_email_before = t sur RESET_PASSWORD, UPDATE_CREDENTIAL ou UPDATE_PASSWORD sont l'indicateur le plus fort que cette CVE a été exploitée. Corrélez la colonne ip_address avec vos journaux d'accès.

Vérifiez Q0 en premier : les événements de connexion expirent (events_expiration) et peuvent être entièrement désactivés. Q1 n'expire pas, c'est donc la vérification la plus fiable.

Si vous trouvez une prise de contrôle

1. Désactivez le compte concerné ou forcez une réinitialisation de mot de passe via un canal de confiance.
2. Révoquez les sessions et les jetons hors ligne du compte (Admin console > Sessions) et renouvelez tout secret auquel il aurait pu accéder.
3. Élargissez l'investigation : journaux du reverse-proxy/ingress autour des horodatages et des IP de Q2, actions effectuées par le compte après le changement de credential, et applications avales fédérées via Keycloak.

Mises en garde

• Lecture seule, mais préférez l'exécuter contre une réplique ou une sauvegarde.
• Écrit pour Keycloak 26.x sur PostgreSQL. Les noms de tables sont stables dans les versions récentes, mais vérifiez sur d'autres bases de données ou des versions plus anciennes.
• L'absence de résultat ne prouve pas l'absence de compromission (voir Q0), en particulier avec une courte rétention des événements ou une journalisation désactivée.

Licence

MIT, voir LICENSE. Fourni tel quel, sans garantie.