oscerd/cve-2026-95663Reproductor 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.
Reproductor de prueba de concepto ejecutable para la vulnerabilidad de Apache Camel en la que KeycloakSecurityPolicy con
la introspección de tokens habilitada (useTokenIntrospection=true) seguía aceptando un token de acceso después de que este
hubiera expirado, porque el resultado de introspección en caché sobrevivía al token.
| Runtime | Directorio | Stack |
|---|---|---|
| Camel Spring Boot | camel-spring-boot/ | Spring Boot 3.5.13 + camel-keycloak 4.22.1 |
| Camel Quarkus | camel-quarkus/ | Camel Quarkus 3.39.0 (Quarkus 3.39.0, Camel 4.22.0) |
En la ruta de introspección, Keycloak informa un token como inactivo una vez que su exp ha pasado — por lo que el
flag active es lo que aplica la expiración. Los resultados de introspección se almacenan en caché por defecto
(introspectionCacheEnabled=true, introspectionCacheTtl=60), y ambas cachés incluidas
(ConcurrentMapTokenCache, CaffeineTokenCache) expiraban una entrada un tiempo fijo después de que se insertara,
sin acotar esa vida útil por el claim exp que la respuesta en caché ya llevaba.
KeycloakSecurityProcessor, a su vez, comprobaba solo active y nunca comparaba exp con la hora actual.
Una respuesta almacenada en caché poco antes de que el token expirara se servía por lo tanto a solicitudes posteriores que portaban el mismo
token, las cuales eran admitidas con los roles y permisos que el token expirado había llevado — aunque la RFC 7662
establece que una respuesta que contiene exp no debe almacenarse en caché más allá de ese momento.
cd camel-spring-boot # or: cd camel-quarkus
mvn clean package
docker compose up -d --build
until [ "$(curl -s http://localhost:8080/exploit/ready)" = "Started" ]; do sleep 1; done
curl -s http://localhost:8080/exploit/attack # takes ~4s: it waits for the token to expire
docker compose down
En una compilación afectada (idéntico en ambos runtimes):
1) Request while the token is still valid
introspection calls so far: 1
outcome: [ADMITTED - the protected route ran]
... the token's exp has now passed. The cache entry is still inside its 60s TTL.
2) The same token again, now expired, against the SAME route
introspection calls so far: 1 (unchanged - the endpoint was never asked again)
outcome: [ADMITTED - the protected route ran]
an expired token was admitted: true
3) CONTROL - the same expired token against a route with introspectionCacheEnabled=false
introspection calls so far: 2 (the endpoint was asked)
outcome: [REJECTED - CamelAuthorizationException: Token is not active (may be revoked or expired)]
rejected once the endpoint was actually consulted: true
>>> PROVEN: ...
El contador de llamadas de introspección es la evidencia: no se mueve entre la sonda 1 y la sonda 2. Nunca se consultó al proveedor de identidad por segunda vez, por lo que su veredicto —que para entonces es "inactivo"— nunca llegó a la política. La sonda 3 demuestra que ese veredicto existe: el mismo token expirado contra una ruta con el almacenamiento en caché desactivado es rechazado, que es también la solución alternativa que el aviso ofrece para las implementaciones que aún no pueden actualizarse. Reducir introspectionCacheTtl solo estrecha la ventana; no la cierra.
Sin servidor Keycloak y sin red. La aplicación aloja un sustituto del endpoint de introspección de Keycloak, en la ruta exacta que construye KeycloakTokenIntrospector
({serverUrl}/realms/{realm}/protocol/openid-connect/token/introspect), que se comporta como lo hace Keycloak:
activo hasta que exp ha pasado, inactivo después, con exp, iss y realm_access.roles en la
respuesta. Se ejecutan el KeycloakSecurityPolicy real, el KeycloakTokenIntrospector real y la caché real.
La introspección no requiere que el token sea un JWT, por lo que el token aquí es una cadena opaca — el exp
que importa reside en la respuesta de introspección, que es exactamente lo que la caché no estaba respetando.
El problema no concede nada más allá de lo que el token ya portaba: ni falsificación de tokens ni escalada de privilegios. La ventana está acotada por introspectionCacheTtl — 60 segundos por defecto, 300 a 600 donde se siguió la recomendación de la documentación para servicios internos — y solo se abre para un token que el mismo proceso Camel introspeccionó y almacenó en caché mientras aún estaba activo. La introspección de tokens no está habilitada por defecto. De ahí la severidad media.
La ruta de verificación local de JWT, utilizada cuando la introspección está deshabilitada, no se ve afectada.
| Propiedad | Valor |
|---|---|
| Componente | camel-keycloak (KeycloakSecurityPolicy con useTokenIntrospection=true) |
| CWE | CWE-613 (Expiración de sesión insuficiente) |
| Severidad | Media |
| Vector de ataque | Un llamador que vuelve a presentar un token de portador que era válido momentos antes, dentro del TTL de la caché de introspección |
| Impacto | Solicitudes admitidas después de la expiración del token, con los roles y permisos que ese token portaba |
| Versiones afectadas | Desde 4.16.0 anterior a 4.18.5, desde 4.19.0 anterior a 4.22.2 |
| Versiones corregidas | 4.18.5, 4.22.2, 4.23.0 |
| JIRA | CAMEL-24902 |
| Crédito | Andrea Cosentino de Apache Software Foundation |
Aviso: https://camel.apache.org/security/CVE-2026-95663.html
Dos cambios independientes:
introspectionCacheTtl
y el tiempo restante hasta el exp del token, y un resultado cuyo token ya ha expirado nunca se
sirve desde la caché.KeycloakSecurityProcessor ahora rechaza un token cuyo exp está en el pasado
en todas las rutas que utilizan introspección, por lo que la expiración se aplica allí como ya se hacía en la ruta
de verificación local de JWT.Una respuesta que no lleva ninguna reclamación exp conserva el tiempo de vida configurado.
Corregido en main en apache/camel#26747 (7bfacb70), retroportado
a camel-4.22.x en #27182 (66fd7034) y a
camel-4.18.x en #27183 (6be02c19).
Establezca camel.version en 4.22.2 y ejecútelo de nuevo. Verificado con 4.22.1 → 4.22.2:
2) The same token again, now expired, against the SAME route
introspection calls so far: 2
outcome: [REJECTED - CamelAuthorizationException: Token is not active (may be revoked or expired)]
an expired token was admitted: false
>>> NOT reproduced: the expired token was rejected.
Observe que el contador pasa de 1 a 2: la vida útil de la entrada de caché estaba limitada por el exp del token, por lo que la
segunda solicitud volvió a realizar la introspección y obtuvo el veredicto real del endpoint.
Este repositorio se publica con fines educativos y defensivos: para ayudar a los usuarios de Apache Camel a comprender la vulnerabilidad, verificar si se ven afectados y confirmar que la actualización la resuelve. No utilice este material contra sistemas que no sean de su propiedad o que no opere.