CVE-2026-95663

Resumen

Vulnerabilidad de expiración de sesión insuficiente en el componente Keycloak de Apache Camel. Este problema afecta a Apache Camel: desde 4.16.0 anterior a 4.18.5, desde 4.19.0 anterior a 4.22.2. Cuando la introspección de tokens está habilitada en la KeycloakSecurityPolicy de camel-keycloak (useTokenIntrospection=true), el procesador de seguridad valida el token de acceso de una solicitud enviándolo al endpoint de introspección de tokens OAuth 2.0 de Keycloak, y acepta el token mientras la respuesta lo reporte como activo. El endpoint de introspección reporta un token como inactivo una vez que ha transcurrido su tiempo exp (de expiración), por lo que en esta ruta el flag active es lo que aplica la expiración del token. Los resultados de introspección se almacenan en caché por defecto (introspectionCacheEnabled=true, introspectionCacheTtl=60 segundos), y ambas implementaciones de caché incluidas con el componente, ConcurrentMapTokenCache y CaffeineTokenCache, expiraban una entrada un tiempo fijo después de su inserción, sin limitar esa vida útil por el claim exp que la respuesta almacenada en caché ya contenía. KeycloakSecurityProcessor, a su vez, comprobaba únicamente el flag active del resultado, en cada ruta que utiliza introspección, y nunca comparaba exp con la hora actual. Por lo tanto, una respuesta almacenada en caché poco antes de que el token expirara se servía a solicitudes posteriores que portaban el mismo token durante hasta el tiempo de vida configurado después de la expiración del token, y esas solicitudes eran admitidas con los roles y permisos que el token expirado había portado, aunque la RFC 7662, que define la introspección de tokens, establece que una respuesta que contenga exp no debe almacenarse en caché más allá de ese momento. El token de acceso es proporcionado por el llamador con cada solicitud, típicamente como un token bearer en la cabecera Authorization, por lo que un llamador que posee un token que era válido momentos antes podía seguir usándolo después de que expirara, durante todo el tiempo que viviera la entrada en caché. La ventana está limitada por introspectionCacheTtl, que es de 60 segundos por defecto y de 300 a 600 segundos cuando se siguió la recomendación de la documentación para servicios internos, y solo se abre para un token que el mismo proceso de Camel introspeccionó y almacenó en caché mientras el token aún estaba activo. El problema no concede nada más allá de lo que el token ya portaba: no permite falsificación de tokens ni escalada de privilegios, y la introspección de tokens no está habilitada por defecto, por lo que la severidad se evalúa como media. La ruta de verificación JWT local, utilizada cuando la introspección está deshabilitada, no se ve afectada por este problema. Se recomienda a los usuarios actualizar a la versión 4.23.0, que corrige el problema. Si los usuarios están en la línea de versiones 4.22.x, se sugiere actualizar a 4.22.2. Si los usuarios están en la línea de versiones 4.18.x, se sugiere actualizar a 4.18.5. Las líneas de versiones 4.16.x, 4.17.x y 4.19.x a 4.21.x alcanzaron el fin de vida antes de que se resolviera este problema y no recibirán una corrección, por lo que las implementaciones en ellas deben migrar a una versión soportada. Para las implementaciones que no puedan actualizar de inmediato, establezcan introspectionCacheEnabled=false en la KeycloakSecurityPolicy, de modo que cada solicitud se compruebe contra el endpoint de introspección, que reporta un token expirado como inactivo, a costa de una llamada de introspección por solicitud. Reducir introspectionCacheTtl solo estrecha la ventana y no la cierra.

Fuentes

• CVE-2026-95663PoC

  Reproductor ejecutable de prueba de concepto para CVE-2026-95663, donde Apache Camel camel-keycloak servía resultados de introspección de tokens en caché más allá de la expiración del token, con demos de Spring Boot y Quarkus.