CVE-2026-88900

Resumen

Vulnerabilidad de deserialización de datos no confiables en el componente Camel-Jgroups de 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. JGroupsEndpoint.createExchange(Message), que CamelJGroupsReceiver invoca para cada mensaje que el consumidor de jgroups recibe antes de que se enrute el exchange, establecía el cuerpo del exchange a partir de org.jgroups.Message.getObject(). Para un ObjectMessage, que es el tipo de mensaje que envía el productor de Camel jgroups, JGroups deserializa en Java la carga útil mediante un ObjectInputStream en su propio hilo de recepción a medida que llega el mensaje, y getObject() devuelve el objeto resultante. No se aplicó ningún java.io.ObjectInputFilter en esa ruta a menos que el despliegue hubiera establecido un filtro de serialización a nivel de JVM: camel-jgroups no instaló ninguno, y las versiones de JGroups incluidas con las versiones afectadas no aplican ninguno propio, por lo que cualquier clase serializable en el classpath de la aplicación podía instanciarse y ejecutar sus callbacks de deserialización. A menos que se configure un canal o la opción channelProperties, el consumidor crea su canal con new JChannel(), la pila de protocolos estándar de JGroups, que realiza multidifusión sobre UDP sin el protocolo AUTH y sin cifrado, por lo que cualquier host capaz de alcanzar el grupo de multidifusión o el puerto de escucha del clúster puede unirse al clúster y enviar mensajes al consumidor sin credenciales. Dicho host podría enviar un objeto serializado manipulado que conduzca a la ejecución remota de código en el proceso de Camel cuando haya presente en el classpath una cadena de gadgets de deserialización utilizable, y no se requería ninguna opción no predeterminada en el consumidor. Dado que JGroups materializa el objeto antes de que se ejecute el receptor de Camel, una comprobación realizada por Camel solo puede inspeccionar el resultado deserializado y no puede detener el código que se ejecuta durante la deserialización, por lo que cerrar el problema también requiere un control que se aplique antes de que se lea la carga útil, tal como se describe en la mitigación. La explotación requiere acceso de red al grupo de multidifusión o al puerto de escucha del clúster, lo que con el transporte de multidifusión UDP predeterminado significa un host en una red adyacente, y una cadena de gadgets utilizable en el classpath, razón por la cual la gravedad se evalúa como alta en lugar de crítica. 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.1. Si los usuarios están en la línea de versiones 4.18.x, se sugiere actualizar a 4.18.5. La línea de versiones 4.14.x y anteriores, y las líneas de versiones 4.15.x a 4.17.x y 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 esas líneas deben migrar a una versión compatible.