CVE-2026-94386

Resumen

Vulnerabilidad por uso de caché que contiene información sensible en el componente Oauth de Apache Camel. Este problema afecta a Apache Camel: desde 4.19.0 hasta antes de 4.22.2. OAuthClientCredentialsTokenResolver obtiene tokens de portador OAuth 2.0 mediante la concesión de credenciales de cliente en nombre de los componentes que autentican sus llamadas salientes con un perfil OAuth con nombre, como camel-openai, camel-langchain4j-agent, camel-huggingface, camel-docling, camel-a2a, camel-spring-ai-chat y los componentes de IBM watsonx, y de las aplicaciones que llaman directamente a la SPI OAuthClientAuthenticationFactory. Mantenía los tokens obtenidos en una caché estática compartida por cada instancia de resolver y cada CamelContext de la JVM, y usaba como clave de esa caché únicamente el endpoint del token y el ID de cliente, aunque la solicitud de token también incluye el secreto de cliente y el scope solicitado. Por lo tanto, dos perfiles que comparten un endpoint de token y un ID de cliente pero solicitan scopes diferentes, o se autentican con secretos de cliente diferentes, se asignaban a la misma entrada de caché: el perfil que resolvía un token primero llenaba la entrada, y al otro perfil se le entregaba después ese token, sin realizar ninguna solicitud de token con su propia configuración, mientras el token siguiera siendo válido. El almacenamiento en caché de tokens está habilitado de forma predeterminada, y apuntar varios perfiles a un mismo cliente de proveedor de identidad es un uso habitual del soporte de perfiles, no una opción de adhesión a una configuración insegura. El resultado es una solicitud saliente que lleva un token emitido para el scope de otro perfil, lo que puede conceder una autoridad más amplia que aquella para la que estaba configurado el perfil llamante, o alcanzar un servicio para el que no se emitió el token; con proveedores de identidad que derivan la audiencia de un token a partir del scope solicitado, un scope diferente puede significar un token para un servicio completamente distinto. A un perfil configurado con un secreto de cliente diferente también se le servía el token obtenido con el otro secreto, sin autenticarse con el suyo propio. Los perfiles son configurados por el despliegue, que es de confianza, por lo que ninguna entrada no confiable llega a la caché: la parte que se beneficia es el servicio que recibe un token que no estaba destinado a recibir, el cual, si es hostil o está comprometido, puede reutilizar ese token dentro de su scope. Alcanzar el problema requiere un despliegue que defina más de un perfil que comparta un endpoint de token y un ID de cliente pero difiera en el scope o en el secreto de cliente. Se recomienda a los usuarios actualizar a la versión 4.23.0, que corrige el problema. Si los usuarios están en la rama de versiones 4.22.x, se sugiere actualizar a 4.22.2. Las líneas de versiones 4.19.x a 4.21.x alcanzaron el fin de su ciclo de vida antes de que se resolviera este problema y no recibirán una corrección, por lo que los despliegues en ellas deben pasar a una versión compatible. Para los despliegues que no puedan actualizar de inmediato, deshabiliten el almacenamiento en caché de tokens en cada perfil OAuth que comparta un endpoint de token y un ID de cliente con otro perfil, estableciendo camel.oauth.NAME.cache-tokens=false para un perfil con nombre o camel.oauth.cache-tokens=false para el predeterminado, de modo que cada resolución solicite un token con el scope y el secreto de cliente propios de ese perfil, a costa de una solicitud de token en cada resolución. Alternativamente, registren un cliente separado en el proveedor de identidad para cada perfil que necesite un scope o un secreto de cliente diferentes, de modo que no haya dos de esos perfiles que compartan un ID de cliente.

Fuentes

• CVE-2026-94386PoC

  Reproductor ejecutable de Spring Boot y Quarkus para CVE-2026-94386, que demuestra la reutilización de tokens OAuth entre ámbitos en la caché de tokens estática de camel-oauth de Apache Camel.