CVE-2026-78165

Resumo

Vulnerabilidade de desserialização de dados não confiáveis no componente Apache Camel Spring Redis. Este problema afeta o Apache Camel: de 2.11.0 até antes de 4.18.5, de 4.19.0 até antes de 4.22.1. RedisConfiguration.getSerializer criava de forma preguiçosa um JdkSerializationRedisSerializer simples sempre que nenhuma opção de serializador era configurada, e essa instância era usada em todas as leituras realizadas pelo componente. A implementação do Spring delega por meio de DeserializingConverter para DefaultDeserializer, que lê os bytes com um ConfigurableObjectInputStream e não instala nenhum java.io.ObjectInputFilter no fluxo, de modo que um grafo de classes serializado arbitrário era materializado e seu método readObject era executado. RedisConsumer.setBody aplicava esse serializador aos bytes brutos de cada mensagem publicada nos canais subscritos, antes que o Exchange fosse construído e, portanto, antes que qualquer lógica de rota pudesse inspecionar a mensagem, de modo que um ator capaz de emitir PUBLISH em um canal subscrito alcançava diretamente o sink de desserialização. O mesmo serializador padrão servia de base para o RedisTemplate construído por RedisConfiguration.createDefaultTemplate, de modo que os comandos de leitura do produtor GET, HGET, HGETALL e HVALS desserializavam o que quer que estivesse armazenado no keyspace do Redis, e o SpringRedisIdempotentRepository compartilhava esse template. Configurar um redisTemplate personalizado não fechava o caminho do consumidor, porque RedisConsumer.setBody lê getSerializer diretamente em vez do serializador anexado ao template, de modo que uma implantação que tivesse conectado um serializador String ao seu próprio template permanecia exposta no lado do consumidor, a menos que também definisse a opção serializer. O componente nunca construía um java.io.ObjectInputStream por conta própria, razão pela qual verificações anteriores no código do Camel em busca de desserialização Java sem filtro não o alcançaram. O comportamento remonta à introdução do componente, lançado pela primeira vez na 2.11.0, e permaneceu inalterado até esta correção. Recomenda-se que os usuários atualizem para a versão 4.23.0, que corrige o problema. Se os usuários estiverem no fluxo de versões 4.22.x, sugere-se que atualizem para 4.22.1. Se os usuários estiverem no fluxo de versões 4.18.x, sugere-se que atualizem para 4.18.5. O fluxo de versões 4.14.x e anteriores atingiu o fim de vida antes que este problema fosse resolvido e não receberá correção, portanto implantações nessas linhas devem migrar para uma versão suportada. Para implantações que não podem atualizar imediatamente, defina a propriedade de sistema jdk.serialFilter em toda a JVM, que o caminho de código afetado respeita porque lê por meio de um java.io.ObjectInputStream, por exemplo -Djdk.serialFilter=!java.net.**;java.**;javax.**;org.apache.camel.**;!* ; ou defina a opção de endpoint serializer para um serializador que não use serialização Java, como StringRedisSerializer, observando que isso deve ser definido como a opção serializer e não apenas em um redisTemplate personalizado. Como defesa em profundidade, exija autenticação na instância do Redis e restrinja quais clientes podem publicar nos canais subscritos, e não exponha uma instância do Redis consumida pelo Camel a redes não confiáveis.