CVE-2026-43866

Resumo

# Vulnerabilidade de Desserialização de Dados Não Confiáveis no Apache Camel, componente Apache Camel JMS Vulnerabilidade de Desserialização de Dados Não Confiáveis no Apache Camel, componente Apache Camel JMS. O `JmsBinding.extractBodyFromJms()` no camel-jms — e o `JmsBinding` equivalente no camel-sjms — desserializa o payload de uma JMS ObjectMessage recebida via `jakarta.jms.ObjectMessage.getObject()` sempre que a opção `mapJmsMessage` está habilitada (o padrão) e o Camel atua como consumidor JMS. O endurecimento do CVE-2026-40860 adicionou uma verificação de classe pós-desserialização que rejeita classes fora da allow-list padrão `java.**;javax.**;org.apache.camel.**;!*`. No entanto, o próprio `org.apache.camel.support.DefaultExchangeHolder` reside no namespace `org.apache.camel.**` incluído na allow-list, portanto uma ObjectMessage cujo objeto de nível superior seja um `DefaultExchangeHolder` passa na verificação. O lado receptor então chama `DefaultExchangeHolder.unmarshal()` sobre ele sem exigir que a opção `transferExchange` esteja habilitada — uma fronteira de confiança assimétrica, já que o lado remetente condiciona o tratamento de ObjectMessage e transferExchange, mas o lado receptor não — gravando todos os campos não nulos do holder no Exchange: o corpo da mensagem, os cabeçalhos IN e OUT, as propriedades do exchange, as variáveis, o id do exchange e a exceção. Um atacante que consiga publicar uma ObjectMessage em uma fila ou tópico consumido por uma aplicação Camel afetada pode, portanto, injetar estado arbitrário de Exchange usando apenas tipos `java.lang` e `java.util` universalmente confiáveis, sem exigir cadeia de gadgets de desserialização, para manipular roteamento e cabeçalhos, propriedades de exchange e tratamento de erros. O mesmo tratamento se aplica ao camel-sjms e camel-sjms2, e aos componentes da família JMS construídos sobre JmsComponent e JmsBinding: camel-amqp, camel-activemq e camel-activemq6. Trata-se de uma bypass da correção do CVE-2026-40860, e não de uma falha nela. Este problema afeta o Apache Camel: de 3.0.0 antes de 4.14.8, de 4.15.0 antes de 4.18.3, de 4.19.0 antes de 4.21.0; Apache Camel: de 3.0.0 antes de 4.14.8, de 4.15.0 antes de 4.18.3, de 4.19.0 antes de 4.21.0. Recomenda-se que os usuários atualizem para a versão 4.21.0, que corrige o problema. Se os usuários estiverem no fluxo de releases LTS 4.14.x, recomenda-se atualizar para 4.14.8. Se os usuários estiverem no fluxo de releases 4.18.x, recomenda-se atualizar para 4.18.3. Após a atualização, o tratamento de JMS ObjectMessage fica desabilitado por padrão no camel-jms, camel-sjms e nos componentes da família JMS (uma nova opção `objectMessageEnabled` assume o padrão `false` no nível de componente e endpoint), portanto uma ObjectMessage recebida — incluindo um payload `DefaultExchangeHolder` — não é mais desserializada a menos que a opção seja explicitamente habilitada; defina `objectMessageEnabled=true` somente quando o destino JMS consumido for alimentado exclusivamente por produtores confiáveis. Para implantações que não podem atualizar imediatamente, restrinja o acesso de publicação às filas e tópicos consumidos pelo Camel a produtores confiáveis por meio da autorização do broker JMS, e não exponha consumidores JMS que mapeiem corpos de ObjectMessage a redes não confiáveis; uma allow-list de desserialização do provedor JMS não mitiga esta bypass específica porque o payload malicioso usa apenas classes universalmente confiáveis.