CVE-2026-66908

Resumen

Vulnerabilidad de autenticación incorrecta en el componente Platform HTTP Main de Apache Camel. Este problema afecta a Apache Camel: desde la versión 4.8.0 hasta antes de la 4.22.0. El servidor HTTP embebido de camel-main puede proteger sus endpoints con autenticación JWT, configurada mediante authenticationEnabled junto con las propiedades del almacén de claves (keystore) JWT. JWTAuthenticationConfigurer.buildJwtOptions devolvía null cuando no se configuraban ni jwtIssuer ni jwtAudience, y el llamador omitía por completo la llamada a JWTAuthOptions.setJWTOptions, de modo que la instancia de Vert.x JWTAuth se construía solo a partir del keystore. El resultado era que los tokens entrantes solo se comprobaban por firma y caducidad: las reclamaciones (claims) iss y aud no se validaban en absoluto. Nada lo señalaba: el servidor se iniciaba con normalidad y no informaba de ninguna advertencia, por lo que un despliegue configurado de la forma documentada aplicaba silenciosamente menos de lo que el operador creía haber habilitado, y la propia documentación del componente presentaba la comprobación de firma y caducidad como el comportamiento predeterminado, con el emisor y la audiencia como una opción adicional. Tanto el servidor de aplicaciones como el servidor de administración se veían afectados, porque la omisión estaba en cada una de las dos rutas de configureAuthentication. Por lo tanto, se aceptaba cualquier token no caducado firmado por cualquier clave que el keystore configurado considere de confianza, independientemente de qué emisor lo hubiera acuñado o para qué audiencia estaba destinado. El alcance de esto depende del conjunto de confianza del keystore: cuando la clave de firma pertenece a un proveedor de identidad compartido o multiinquilino, se acepta un token emitido legítimamente para una audiencia completamente distinta, mientras que un keystore que contenga un firmante dedicado lo reduce a la reutilización de tokens emitidos para otros servicios dentro del mismo dominio de confianza. Las opciones jwtIssuer y jwtAudience no existían antes de la 4.21.0, por lo que en versiones anteriores no había ninguna forma compatible de hacer cumplir estas reclamaciones. Se recomienda a los usuarios actualizar a la versión 4.22.0, que corrige el problema. Desde la 4.22.0, el servidor se niega a iniciarse cuando hay un keystore JWT configurado pero no se establecen ni jwtIssuer ni jwtAudience, indicando las propiedades implicadas, y un despliegue que realmente solo quiera validación de firma y caducidad debe declararlo explícitamente con la nueva opción jwtAllowMissingIssuerAndAudience, cuyo valor predeterminado es false. Este comportamiento solo se corrige en la 4.22.0. Las versiones 4.14.9 y 4.18.4 no cambian el valor predeterminado: añaden las opciones jwtIssuer y jwtAudience para que los operadores en esas líneas de mantenimiento puedan hacer cumplir las reclamaciones mediante configuración, y una instalación que actualice a 4.14.9 o 4.18.4 sin establecer también al menos una de esas dos propiedades sigue aceptando cualquier token no caducado firmado por una clave de confianza. Por lo tanto, los usuarios de 4.14.x o 4.18.x deberían actualizar a 4.14.9 o 4.18.4 y luego establecer jwtIssuer, jwtAudience o ambas. Las versiones desde la 4.8.0 hasta la 4.21.x inclusive no ofrecen forma de hacer cumplir estas reclamaciones y deberían migrarse a una versión que sí lo haga. Independientemente de la versión, restrinja el keystore JWT al conjunto de confianza más pequeño posible - idealmente, un firmante dedicado a este servicio en lugar de una clave compartida de proveedor de identidad - y, cuando una puerta de enlace ya valide el emisor y la audiencia delante del servidor, asegúrese de que no se pueda omitir. Notas: El ticket de JIRA: https://issues.apache.org/jira/browse/CAMEL-24281 hace referencia a los diversos commits que resolvieron el problema y contiene más detalles. La protección de cierre ante fallos (fail-closed) no pudo trasladarse a versiones anteriores. Las opciones jwtIssuer y jwtAudience solo se introdujeron en la 4.21.0 mediante CAMEL-23525, por lo que en camel-4.18.x y camel-4.14.x no había nada que un operador pudiera establecer para cumplir el requisito, y la protección habría roto todos los despliegues JWT en esas ramas sin remedio disponible.