CVE-2026-43866

Resumen

# Vulnerabilidad de Deserialización de Datos No Confiables en Apache Camel, componente Apache Camel JMS JmsBinding.extractBodyFromJms() en camel-jms — y el JmsBinding equivalente en camel-sjms — deserializa el payload de un JMS ObjectMessage entrante mediante jakarta.jms.ObjectMessage.getObject() siempre que la opción mapJmsMessage esté habilitada (el valor predeterminado) y Camel actúe como consumidor JMS. El endurecimiento de CVE-2026-40860 añadió una comprobación de clases posterior a la deserialización que rechaza clases fuera de la lista de permitidos predeterminada java.**;javax.**;org.apache.camel.**;!*. Sin embargo, org.apache.camel.support.DefaultExchangeHolder reside en el espacio de nombres org.apache.camel.** incluido en la lista de permitidos, por lo que un ObjectMessage cuyo objeto de nivel superior sea un DefaultExchangeHolder supera la comprobación. El lado receptor entonces llama a DefaultExchangeHolder.unmarshal() sobre él sin requerir que la opción transferExchange esté habilitada — un límite de confianza asimétrico, ya que el lado emisor controla el manejo de ObjectMessage y transferExchange pero el lado receptor no lo hacía — escribiendo cada campo no nulo del holder en el Exchange: el cuerpo del mensaje, los encabezados IN y OUT, las propiedades del exchange, las variables, el id del exchange y la excepción. Un atacante que pueda publicar un ObjectMessage en una cola o tema consumido por una aplicación Camel afectada puede, por tanto, inyectar estado arbitrario del Exchange utilizando únicamente tipos java.lang y java.util universalmente confiables, sin necesidad de una cadena de gadgets de deserialización, para manipular el enrutamiento y los encabezados, las propiedades del exchange y el manejo de errores. El mismo manejo se aplica a camel-sjms y camel-sjms2, y a los componentes de la familia JMS construidos sobre JmsComponent y JmsBinding: camel-amqp, camel-activemq y camel-activemq6. Esto es una evasión de la corrección de CVE-2026-40860 más que un fallo en ella. Este problema afecta a Apache Camel: desde 3.0.0 antes de 4.14.8, desde 4.15.0 antes de 4.18.3, desde 4.19.0 antes de 4.21.0; Apache Camel: desde 3.0.0 antes de 4.14.8, desde 4.15.0 antes de 4.18.3, desde 4.19.0 antes de 4.21.0. Se recomienda a los usuarios actualizar a la versión 4.21.0, que corrige el problema. Si los usuarios están en la rama de versiones LTS 4.14.x, se les sugiere actualizar a 4.14.8. Si los usuarios están en la rama de versiones 4.18.x, se les sugiere actualizar a 4.18.3. Después de la actualización, el manejo de JMS ObjectMessage está deshabilitado por defecto en camel-jms, camel-sjms y los componentes de la familia JMS (una nueva opción objectMessageEnabled tiene como valor predeterminado false a nivel de componente y endpoint), por lo que un ObjectMessage entrante — incluido un payload DefaultExchangeHolder — ya no se deserializa a menos que la opción se habilite explícitamente; solo establezca objectMessageEnabled=true cuando el destino JMS consumido sea alimentado exclusivamente por productores confiables. Para implementaciones que no puedan actualizar de inmediato, restrinja el acceso de publicación a las colas y temas consumidos por Camel a productores confiables mediante la autorización del broker JMS, y no exponga consumidores JMS que mapeen cuerpos de ObjectMessage a redes no confiables; una lista de permitidos de deserialización del proveedor JMS no mitiga esta evasión específica porque el payload manipulado utiliza únicamente clases universalmente confiables.