CVE-2026-88900

Resumo

Vulnerabilidade de Desserialização de Dados Não Confiáveis no componente Camel-Jgroups do Apache Camel. Este problema afeta o Apache Camel: de 4.0.0 antes de 4.18.5, de 4.19.0 antes de 4.22.1. JGroupsEndpoint.createExchange(Message), que o CamelJGroupsReceiver chama para cada mensagem que o consumidor jgroups recebe antes de o exchange ser roteado, definia o corpo do exchange a partir de org.jgroups.Message.getObject(). Para uma ObjectMessage, que é o tipo de mensagem que o produtor Camel jgroups envia, o JGroups desserializa o payload em Java por meio de um ObjectInputStream em sua própria thread de recebimento à medida que a mensagem chega, e getObject() retorna o objeto resultante. Nenhum java.io.ObjectInputFilter era aplicado nesse caminho, a menos que a implantação tivesse definido um filtro de serialização em todo o JVM: o camel-jgroups não instalava nenhum, e as versões do JGroups fornecidas com as versões afetadas não aplicam nenhum por conta própria, de modo que qualquer classe serializável no classpath da aplicação poderia ser instanciada e seus callbacks de desserialização executados. A menos que um canal ou a opção channelProperties esteja configurada, o consumidor cria seu canal com new JChannel(), a pilha de protocolos padrão do JGroups, que faz multicast sobre UDP sem o protocolo AUTH e sem criptografia, de modo que qualquer host capaz de alcançar o grupo multicast do cluster ou a porta de bind pode ingressar no cluster e enviar mensagens ao consumidor sem credenciais. Tal host poderia enviar um objeto serializado especialmente criado que leva à execução remota de código no processo Camel quando uma cadeia de gadgets de desserialização utilizável está presente no classpath, e nenhuma opção não padrão era exigida no consumidor. Como o JGroups materializa o objeto antes de o receptor do Camel ser executado, uma verificação realizada pelo Camel só pode inspecionar o resultado desserializado e não pode impedir código que é executado durante a desserialização, portanto, encerrar o problema também exige um controle que se aplique antes de o payload ser lido, conforme descrito na mitigação. A exploração exige acesso de rede ao grupo multicast do cluster ou à porta de bind, o que, com o transporte multicast UDP padrão, significa um host em uma rede adjacente, e uma cadeia de gadgets utilizável no classpath, razão pela qual a severidade é avaliada como alta e não crítica. 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, e as linhas de versões 4.15.x a 4.17.x e 4.19.x a 4.21.x, atingiram o fim de vida antes de este problema ser resolvido e não receberão correção, portanto, as implantações nessas linhas devem migrar para uma versão suportada.