CVE-2026-78165
Apache Camel: deserialización Java sin filtro de cargas útiles de Redis en Camel-Spring-Redis
- Publicado
- 19 oct 2026
- Actualizado
- 20 oct 2026
- Asignación de CNA
- apache
- Evidencia observada
- 17 oct 2026
CVSS primario
cvelist · CVSS 3.1
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HResumen
Vulnerabilidad de deserialización de datos no confiables en el componente Apache Camel Spring Redis. Este problema afecta a Apache Camel: desde 2.11.0 hasta antes de 4.18.5, desde 4.19.0 hasta antes de 4.22.1. RedisConfiguration.getSerializer creaba de forma diferida un JdkSerializationRedisSerializer básico siempre que no se configuraba ninguna opción de serializador, y esa instancia se utilizaba para cada lectura que realiza el componente. La implementación de Spring delega a través de DeserializingConverter en DefaultDeserializer, que lee los bytes con un ConfigurableObjectInputStream y no instala ningún java.io.ObjectInputFilter en el flujo, por lo que se materializaba un grafo de clases serializado arbitrario y se ejecutaba su método readObject. RedisConsumer.setBody aplicaba ese serializador a los bytes sin procesar de cada mensaje publicado en los canales suscritos, antes de que se construyera el Exchange y, por tanto, antes de que cualquier lógica de ruta pudiera inspeccionar el mensaje, de modo que un actor capaz de emitir PUBLISH en un canal suscrito alcanzaba directamente el sumidero de deserialización. El mismo serializador predeterminado respaldaba el RedisTemplate construido por RedisConfiguration.createDefaultTemplate, por lo que los comandos de lectura del productor GET, HGET, HGETALL y HVALS deserializaban lo que estuviera almacenado en el espacio de claves de Redis, y SpringRedisIdempotentRepository compartía ese template. Configurar un redisTemplate personalizado no cerraba la ruta del consumidor, porque RedisConsumer.setBody lee getSerializer directamente en lugar del serializador asociado al template, por lo que un despliegue que hubiera conectado un serializador String a su propio template seguía expuesto en el lado del consumidor a menos que también estableciera la opción serializer. El componente nunca construía por sí mismo un java.io.ObjectInputStream, razón por la cual las revisiones anteriores del código base de Camel en busca de deserialización Java sin filtro no lo alcanzaron. El comportamiento se remonta a la introducción del componente, publicado por primera vez en 2.11.0, y permaneció sin cambios hasta esta corrección. 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, establezcan la propiedad del sistema jdk.serialFilter a nivel de JVM, que la ruta de código afectada respeta porque lee a través de un java.io.ObjectInputStream, por ejemplo -Djdk.serialFilter=!java.net.**;java.**;javax.**;org.apache.camel.**;!* ; o establezcan la opción de endpoint serializer a un serializador que no utilice serialización Java, como StringRedisSerializer, teniendo en cuenta que esto debe establecerse como la opción serializer y no solo en un redisTemplate personalizado. Como defensa en profundidad, exijan autenticación en la instancia de Redis y restrinjan qué clientes pueden publicar en los canales suscritos, y no expongan a redes no confiables una instancia de Redis consumida por Camel.
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.