1 de octubre de 2026 · Security-Advisory · Schwachstellenmanagement · IT-Sicherheit · Zero Trust

Actualización de seguridad de Keycloak: a 26.7.5 o posterior

Keycloak 26.7.4 y 26.7.5 cierran una serie de vulnerabilidades, entre ellas una escalada de privilegios a través del rol de impersonation. Objetivo: 26.7.5 o posterior.

El proyecto Keycloak ha publicado, con poco intervalo, dos versiones de mantenimiento con correcciones de seguridad. 26.7.4 (16 de septiembre) cierra las seis vulnerabilidades descritas aquí, y 26.7.5 (30 de septiembre), otras más: sus notas de versión enumeran 14 correcciones de seguridad, cuatro de ellas en dependencias. El 1 de octubre siguió además 26.8.0. El objetivo para los operadores es, por tanto, 26.7.5 o posterior. Una de las vulnerabilidades de 26.7.4 permite a una cuenta con derechos de administración limitados hacerse pasar por administrador del realm.

Este artículo se dirige a las organizaciones que operan Keycloak por sí mismas, como inicio de sesión central para empleados, para portales de clientes o para aplicaciones de negocio. Clasifica las seis vulnerabilidades de 26.7.4 y describe qué hacer antes y después de la actualización.

Por qué un proveedor de identidad merece una atención especial

Un proveedor de identidad (IdP) no es un servicio más. Emite los tokens en los que confían todas las aplicaciones conectadas. Quien controla el IdP no tiene que atacar cada aplicación por separado: puede iniciar sesión en cualquiera de ellas como quien quiera, y puede modificar los inicios de sesión de forma que nadie lo note.

Por eso, en las arquitecturas de seguridad, un sistema así se asigna al nivel de protección más alto. Microsoft, por ejemplo, cuenta los sistemas de identidad centrales, en su Enterprise Access Model, como parte del plano de control, que surgió del antiguo «Tier 0». Un IdP es, por tanto, tan crítico como los controladores de dominio. De ello se derivan tres reglas prácticas: allí no se aplazan las actualizaciones, allí los derechos administrativos se conceden con especial parquedad y allí los accesos de administración no son accesibles desde internet. Una vulnerabilidad que en una aplicación de negocio sería «solo» una escalada de privilegios es, en el IdP, una escalada de privilegios para todo lo que depende de él.

Las seis vulnerabilidades de 26.7.4

Las clasificaciones proceden de los issues del proyecto y de la GitHub Advisory Database.

CVE-2026-17526 – Escalada de privilegios a través del rol de impersonation (alta, CVSS 7.2). Un usuario con el rol «impersonation» puede suplantar a un administrador del realm y obtiene así, según la descripción del advisory, el control administrativo total sobre el realm, incluida la gestión de usuarios, clientes y roles. Es la vulnerabilidad con mayor palanca, porque convierte un rol limitado deliberadamente en uno ilimitado.

CVE-2026-74909 – Elusión del Policy Enforcer (alta, CVSS 8.1). El Policy Enforcer no normaliza correctamente las rutas con determinados caracteres codificados, por ejemplo un punto y coma codificado en porcentaje. Un usuario autenticado puede así activar una política menos estricta de lo previsto y acceder a endpoints protegidos. El proyecto califica expresamente la corrección como subsanación de un fix anterior incompleto. Esto es relevante para las aplicaciones que aplican sus reglas de acceso a través del Keycloak Policy Enforcer.

CVE-2026-90997 – Reutilización de artefactos de un solo uso (alta). Afecta al modo de funcionamiento sin estado con MySQL o MariaDB. Debido a una forma distinta de contar las filas de base de datos afectadas, la protección contra repetición no reconoce los artefactos ya utilizados. Se mencionan las JWT client assertions, las pruebas DPoP y los códigos TOTP no reutilizables: quien intercepta un artefacto así puede volver a usarlo en el endpoint de tokens o en el flujo de inicio de sesión. Según el issue, la revocación de tokens no está afectada.

CVE-2026-79651 – Denegación de servicio mediante etiquetas de idioma (alta, CVSS 7.5). Los endpoints de localización incorporan a una caché de memoria ilimitada etiquetas de idioma arbitrarias procedentes de solicitudes no autenticadas. Bastan muchas etiquetas distintas para hacer caer el servidor.

CVE-2026-18212 – Fuga de memoria en el SAML Redirect Binding (CVSS 7.5 en la GitHub Advisory Database, marcada como «medium» en el issue del proyecto). La memoria nativa no se libera al procesar solicitudes SAML. Las solicitudes erróneas repetidas sin autenticación agotan la memoria hasta que el sistema operativo termina el proceso.

CVE-2026-19607 – Bloqueo de cuenta por colisión de nombres de usuario (media, CVSS 5.3). En el flujo del primer inicio de sesión a través de un proveedor de identidad externo, un atacante puede registrar un nombre de usuario coincidente en el proveedor externo y provocar así una colisión que bloquea al usuario legítimo. Esto es relevante para todos los realms en los que los usuarios inician sesión a través de un proveedor de identidad externo, por ejemplo mediante una federación con un socio o un social login.

Dos de las seis vulnerabilidades pueden explotarse sin autenticación para hacer caer el servicio. Para un servicio de inicio de sesión central, tampoco una caída es un tema menor: si el IdP se detiene, se detiene todo lo que depende de él.

Qué hacer ahora

  • Actualizar a 26.7.5 o posterior. Antes de la actualización, el proyecto remite a la guía de migración con la lista completa de cambios. Léala antes de la actualización, no después, y pruebe la actualización en una instancia de staging con una configuración realista, en particular las conexiones con proveedores de identidad, los clientes SAML y los temas propios.
  • Determinar la versión. Las notas de versión no indican rangos de versiones afectadas. Parta, por tanto, de que cualquier versión anterior a 26.7.4 puede estar afectada, y compruebe para las líneas 26.4 y 26.6 si el fabricante ofrece versiones corregidas.
  • Revisar el rol de impersonation, y hacerlo antes de la actualización. El rol «impersonation» es un rol de cliente del cliente integrado «realm-management» en cada realm; para la administración entre realms existen roles equivalentes en los clientes <Realm-Name>-realm del realm maestro. Determine qué usuarios, grupos y roles compuestos lo contienen directa o indirectamente. La documentación menciona como finalidad típica el soporte: reproducir un problema desde la perspectiva del usuario afectado. Revise, por tanto, especialmente las cuentas de helpdesk y de soporte. En las versiones afectadas, cualquier cuenta con este rol podía convertirse en administrador del realm.
  • Buscar rastros. En las sesiones suplantadas, Keycloak registra como nota de sesión el identificador y el nombre de usuario de la cuenta suplantadora. Compruebe, en la medida en que registre eventos de administración y eventos de inicio de sesión, si se suplantaron cuentas de administrador y si en ese contexto se modificaron roles, clientes o ajustes de proveedores de identidad.
  • Mantener después el rol restringido. También tras la actualización rige lo siguiente: quien puede suplantar puede iniciar sesión como otra persona. Conceda el rol solo donde se necesite y utilice los permisos de administración de grano fino para excluir por principio la suplantación de administradores.
  • Revisar la base de datos y el modo de funcionamiento. Si opera el modo sin estado con MySQL o MariaDB, CVE-2026-90997 le afecta directamente.

Planificar la actualización sin aplazarla

Una actualización del IdP afecta a cada inicio de sesión, y precisamente por eso se suele aplazar. La guía de actualización (Upgrading Guide) del proyecto marca las pautas. A partir de Keycloak 26.6.0 se admiten las rolling updates para versiones de parche; si son posibles en su entorno lo describe la guía sobre rolling updates. Quien ya está en 26.7 puede, en su caso, actualizar dentro de esa línea sin interrupción; el paso de 26.6 a 26.7 es una actualización menor y, según la Upgrading Guide, requiere una parada.

La guía establece además que primero se actualiza el servidor y después los adaptadores. Antes de cada actualización, la guía exige una copia de seguridad de la instalación –configuración, temas– y de la base de datos. El trasfondo es importante para planificar la vuelta atrás: Keycloak no admite revertir los cambios en la base de datos. Quien tenga que volver atrás restaura la instalación antigua y la base de datos a partir de la copia de seguridad. Esa copia de seguridad no es, por tanto, un accesorio, sino la única vía de retorno. Créela antes de empezar y compruebe que puede restaurarse.

La administración no tiene cabida en internet

La escalada de privilegios presupone una cuenta con derechos de administración. Cuantas menos cuentas de este tipo existan y menos caminos lleven a la consola de administración, menor es la superficie de ataque, no solo para esta vulnerabilidad, sino para la siguiente. Las páginas de inicio de sesión tienen que ser accesibles; la consola de administración, por regla general, no. Las cuentas de administración deben estar protegidas por autenticación multifactor, y su asignación debe someterse a una recertificación periódica.

Cómo apoya sector7

Le apoyamos con conceptos de roles y permisos, con la gestión de cuentas privilegiadas y con procesos de inicio de sesión seguros con autenticación multifactor. A ello se suman escaneos de vulnerabilidades periódicos con corrección priorizada a través de la gestión de parches. Más información en Ciberseguridad.

Fuentes

Hablemos de su situación.

Concertar una conversación+49 212 240915 0