CVE-2026-18963: toma de control de cuentas en Keycloak, búsqueda de rastros de explotación

Un script de psql que busca en una base de datos PostgreSQL de Keycloak rastros de la explotación de CVE-2026-18963 (toma de control de cuentas sin autenticación a través del flujo de restablecimiento de credenciales).

Publicado por KYOS. Lo escribimos mientras parcheábamos los despliegues de Keycloak que operamos, para verificar que nadie hubiera sido comprometido durante la ventana de exposición.

La vulnerabilidad

CVE-2026-18963 es un fallo en el flujo de restablecimiento de credenciales de keycloak-services (keycloak#51833). Un atacante no autenticado puede completar el proceso de restablecimiento de contraseña de cualquier usuario sin hacer clic en el enlace de verificación por correo y, a continuación, establecer una nueva contraseña en la cuenta. No se requiere interacción del usuario.

Qué significa para los rastros

Comprobado contra Keycloak 26.7.1 en una instancia desechable. No publicamos los pasos de reproducción; los detalles a continuación son los que necesita para leer las consultas.

El flujo rastrea en qué pantalla del autenticador se encuentra de una forma que no está vinculada al paso que la estableció. Eso permite volver a entrar en el flujo de restablecimiento de credenciales en el paso de verificación por correo, donde el vulnerable ResetCredentialEmail.action() devuelve éxito sin comprobar nunca la existencia de un token de acción. La ejecución continúa entonces hasta el formulario de actualización de contraseña.

Dos consecuencias determinan todas las consultas de este repositorio:

• El paso de correo se ejecuta realmente antes del bypass. La víctima recibe un correo de restablecimiento de contraseña genuino y Keycloak registra un evento SEND_RESET_PASSWORD ordinario. La ausencia de ese evento no es una firma.
• El vulnerable action() marca la dirección de correo de la cuenta como verificada antes de retornar. La ruta legítima nunca llega a action(), por lo que se trata de un cambio de estado que solo produce el bypass. La Q3 se basa en esto.

La corrección (keycloak#51844) vincula el estado de la pantalla a la ejecución que lo estableció y solo permite que action() tenga éxito cuando está presente un token de acción para ese usuario exacto.

Gravedad: Crítica, CVSS v3.1 9.1 (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N), según Red Hat y NVD. La causa raíz es una validación de estado incorrecta en el flujo de autenticación, corregida en keycloak#51844.

Versiones afectadas / corregidas

Rama	Corregida en
26.7.x	26.7.2 (notas de la versión)
26.6.x	26.6.6
26.4.x (LTS)	26.4.15
26.8	26.8.0

Todo lo anterior a esas versiones en las ramas soportadas es vulnerable. Las versiones fuera de soporte (26.5.x, 26.3 y anteriores) no reciben corrección: asuma la exposición y actualice a una rama corregida. Red Hat indica que el RH-SSO 7 heredado no está afectado; Red Hat Build of Keycloak 26.4/26.6 está corregido en 26.4.15-1 / 26.6.6-1.

Solución alternativa si no puede parchear de inmediato

Deshabilitar el restablecimiento de contraseña de autoservicio elimina el punto de entrada vulnerable: Consola de administración > Configuración del realm > Inicio de sesión > "¿Olvidó su contraseña?" desactivado, para cada realm. Mediante la API de administración: PUT /admin/realms/{realm} con {"resetPasswordAllowed": false}.

Esto bloquea el endpoint login-actions/reset-credentials, pero también impide que los usuarios legítimos restablezcan su propia contraseña, así que trátelo como una medida provisional hasta que actualice. Tenga en cuenta que Red Hat no indica una mitigación avalada para este CVE; parchear es la única solución real.

Qué no funciona como firma

La primera versión de este script marcaba un restablecimiento completado que no tenía un SEND_RESET_PASSWORD poco antes.

Eso era incorrecto, y vilmosnagy lo señaló tras reproducir el CVE en su propia instancia y observar que el evento aparecía de todos modos. La razón es la primera consecuencia anterior: el autenticador de correo se ejecuta con normalidad, por lo que la víctima recibe un correo de restablecimiento real y Keycloak registra un SEND_RESET_PASSWORD ordinario. La comprobación estaba invertida. Habría borrado todas las cuentas comprometidas que examinara. Ya no está.

Los esquemas basados en tiempos tienen un problema menor pero real. El enfoque del script de búsqueda de thomasdelorge correlaciona SEND_RESET_PASSWORD con UPDATE_PASSWORD sobre un code_id compartido y marca un intervalo corto. La clave de correlación es correcta, y el autor es explícito en que el umbral es heurístico. Nuestras pruebas dicen lo mismo: un restablecimiento eludido y uno legítimo completado en el mismo navegador producen tipos de evento idénticos, claves de detalle idénticas y el mismo code_id. Solo difiere el retraso, lo que deja al umbral cargando con todo el veredicto. Cualquiera que no tenga prisa se mantiene por debajo. Los usuarios reales lo superan, porque el code_id solo permanece igual cuando el enlace se abre en el navegador que inició el flujo, que es también el caso en el que es probable que el correo ya esté abierto.

No encontramos ningún evento, ningún detalle de evento ni ningún error que separe ambos casos. No hay ningún evento de "paso de correo omitido" que buscar. Lo que sí existe es un efecto secundario de estado, y eso es lo que usa Q3.

Qué comprueba el script

cve-2026-18963-keycloak-hunt.sql ejecuta seis consultas de solo lectura:

Consulta	Qué encuentra
Q0	Si el realm almacena eventos, su TTL y si los detalles de los eventos se están persistiendo. Q2 correlaciona por el detalle code_id, así que si faltan los detalles Q2 queda ciego y su silencio no significa nada.
Q1	Cada credencial de contraseña establecida dentro de la ventana de exposición (credential.created_date). Esta es la toma de control en sí, y sobrevive a la expiración de eventos.
Q2	Cada actualización de credencial completada, correlacionada con el correo de restablecimiento de la misma sesión de autenticación, y clasificada. Véase más abajo.
Q3	El efecto secundario determinista: usuarios que están email_verified sin una causa legítima.
Q4	Restablecimientos de credenciales y escrituras de usuario vía Admin-API, para explicar las filas de Q1 y Q3 y descartar la ruta impulsada por el administrador.
Q5	Línea temporal bruta de eventos de restablecimiento/credenciales, para leer un caso concreto a mano.

Veredictos de Q2