CVE-2026-78162
Apache Camel: Instancias gestionadas de Camel-Hazelcast sin filtro de deserialización de Java (corrección incompleta para CVE-2026-43865)
- Publicado
- 19 oct 2026
- Actualizado
- 20 oct 2026
- Asignación de CNA
- apache
- Evidencia observada
- 17 oct 2026
CVSS primario
cvelist · CVSS 4.0
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:HResumen
Vulnerabilidad de deserialización de datos no confiables en Apache Camel. Este problema afecta a Apache Camel: desde 4.0.0 anterior a 4.18.5, desde 4.19.0 anterior a 4.22.1. El componente camel-hazelcast aplica un Hazelcast JavaSerializationFilterConfig predeterminado a las instancias que crea a partir de su propia configuración, una protección introducida por CVE-2026-43865. Ese cambio no llegó a dos de las rutas de configuración que Camel construye por sí mismo, por lo que esas rutas continuaron creando instancias de Hazelcast cuya deserialización Java no está restringida. ReplicatedHazelcastAggregationRepository extiende HazelcastAggregationRepository pero sobrescribe doStart() sin llamar a super.doStart(), manteniendo su propia copia del bloque de arranque y, por lo tanto, nunca recibió el filtro: una ruta que lo utilice sin proporcionar un hazelcastInstance inicia un miembro de Hazelcast que deserializa los valores leídos del ReplicatedMap de respaldo sin ninguna restricción de clase. HazelcastDefaultComponent#getOrCreateHzClientInstance() construye su propio ClientConfig cuando se selecciona hazelcastMode=client y no se proporciona ni un ClientConfig referenciado ni hazelcastConfigUri, y de igual modo no aplicó ningún filtro, por lo que los endpoints en modo cliente se comportaban de forma diferente a los endpoints en modo nodo para una configuración por lo demás idéntica. En ambos casos, un atacante capaz de publicar en el clúster de Hazelcast al que está conectada la instancia afectada puede provocar que un objeto Java serializado de su elección se deserialice dentro de la propia capa de serialización de Hazelcast, antes de que Camel procese el exchange, lo que resulta en ejecución remota de código. Los clústeres de Hazelcast no tienen ni autenticación ni TLS habilitados de forma predeterminada. Seleccionar el modo cliente es una decisión de topología y no una opción de seguridad, por lo que ninguna de las dos rutas requería que el despliegue optara por un comportamiento inseguro. 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.1. Si los usuarios están en la rama de versiones 4.18.x, se sugiere actualizar a 4.18.5. La rama de versiones 4.14.x y anteriores 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 esas líneas deben migrar a una versión compatible. Para los despliegues que no puedan actualizar de inmediato, proporcionen una configuración explícita de Hazelcast que incluya un JavaSerializationFilterConfig, o inyecten una HazelcastInstance preconstruida, ya que Camel nunca sobrescribe una configuración proporcionada por el usuario. Alternativamente, establezcan el filtro a nivel de JVM -Djdk.serialFilter=!java.net.;java.;javax.;org.apache.camel.;!* y habiliten la autenticación de clúster de Hazelcast y TLS para restringir quién puede acceder al clúster.
Uso responsable
Utilice información sobre vulnerabilidades solo en sistemas de su propiedad o que esté autorizado a probar. Kitploit enlaza con metadatos de investigación pública y no almacena código de explotación ni cargas útiles maliciosas.