CVE-2026-78162
Apache Camel: Instâncias Gerenciadas do Camel-Hazelcast com Filtro de Desserialização Java Ausente (Correção Incompleta para CVE-2026-43865)
- Publicado
- 19 de out. de 2026
- Atualizado
- 20 de out. de 2026
- Atribuindo CNA
- apache
- Evidência observada
- 17 de out. de 2026
CVSS primário
cvelist · CVSS 4.0
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:HResumo
Vulnerabilidade de desserialização de dados não confiáveis no Apache Camel. Este problema afeta o Apache Camel: de 4.0.0 até antes de 4.18.5, de 4.19.0 até antes de 4.22.1. O componente camel-hazelcast aplica um Hazelcast JavaSerializationFilterConfig padrão às instâncias que cria a partir de sua própria configuração, uma proteção introduzida pelo CVE-2026-43865. Essa alteração não alcançou dois dos caminhos de configuração que o próprio Camel constrói, de modo que esses caminhos continuaram a criar instâncias Hazelcast cuja desserialização Java é irrestrita. O ReplicatedHazelcastAggregationRepository estende o HazelcastAggregationRepository, mas sobrescreve doStart() sem chamar super.doStart(), mantendo sua própria cópia do bloco de bootstrap e, portanto, nunca recebeu o filtro: uma rota que o utilize sem fornecer um hazelcastInstance inicia um membro Hazelcast que desserializa valores lidos do ReplicatedMap de suporte sem qualquer restrição de classe. O HazelcastDefaultComponent#getOrCreateHzClientInstance() constrói seu próprio ClientConfig quando hazelcastMode=client é selecionado e nem um ClientConfig referenciado nem um hazelcastConfigUri é fornecido, e igualmente não aplicou nenhum filtro, de modo que endpoints em modo cliente se comportaram de forma diferente dos endpoints em modo nó para uma configuração de outra forma idêntica. Em ambos os casos, um atacante capaz de publicar no cluster Hazelcast ao qual a instância afetada está conectada pode fazer com que um objeto Java serializado de sua escolha seja desserializado dentro da própria camada de serialização do Hazelcast, antes que o Camel processe a exchange, resultando em execução remota de código. Os clusters Hazelcast não têm autenticação nem TLS habilitados por padrão. Selecionar o modo cliente é uma escolha de topologia, não uma opção de segurança, portanto nenhum dos caminhos exigia que a implantação optasse por um comportamento inseguro. 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 as implantações nessas linhas devem migrar para uma versão suportada. Para implantações que não podem atualizar imediatamente, forneça uma configuração Hazelcast explícita que carregue um JavaSerializationFilterConfig, ou injete um HazelcastInstance pré-construído, já que uma configuração fornecida pelo usuário nunca é sobrescrita pelo Camel. Alternativamente, defina o filtro de toda a JVM -Djdk.serialFilter=!java.net.;java.;javax.;org.apache.camel.;!* e habilite a autenticação de cluster Hazelcast e TLS para restringir quem pode acessar o cluster.
Uso responsável
Use informações de vulnerabilidade apenas em sistemas que você possui ou está autorizado a testar. O Kitploit vincula-se a metadados de pesquisa pública e não armazena código de exploração ou cargas maliciosas.