CVE-2026-59230
Apache Camel: Camel-Mail: o formato de dados MimeMultipart copiou cabeçalhos MIME para a mensagem Camel sem uma estratégia de filtro de cabeçalhos ao fazer unmarshalling com headersInline ativado
- Publicado
- 24 de ago. de 2026
- Atualizado
- 25 de ago. de 2026
- Atribuindo CNA
- apache
- Evidência observada
- 24 de ago. de 2026
CVSS primário
nvd · CVSS 3.1
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:NBaixo · próximos 30 dias
- Percentil
- 35,8%
- Data do modelo
- 21 de set. de 2026
EPSS é uma estimativa estatística, não uma certeza ou uma medida de impacto. Combine-o com CVSS, status KEV, exposição e seu ambiente.
Resumo
Vulnerabilidade de validação de entrada inadequada no Apache Camel. Este problema afeta o Apache Camel: de 2.17.0 até antes de 4.14.9, de 4.15.0 até antes de 4.18.4, de 4.19.0 até antes de 4.22.0. O componente camel-mail inclui um formato de dados MimeMultipart que pode fazer unmarshal de uma mensagem MIME multipart. Quando configurado com headersInline definido como true, o caminho de unmarshal copia os cabeçalhos MIME da mensagem de entrada para a mensagem Camel: ele enumera todos os cabeçalhos que não sejam um dos três padrão que ele mesmo gera - Message-ID, MIME-Version e Content-Type - e chama setHeader para cada um, sem aplicar nenhuma HeaderFilterStrategy. Os nomes desses cabeçalhos MIME vêm da mensagem que está sendo submetida a unmarshal, portanto um remetente capaz de influenciar a mensagem pode colocar um cabeçalho cujo nome caia no namespace interno do Camel e fazê-lo ser definido no Exchange. Os componentes Camel leem cabeçalhos de controle desse namespace para substituir seu comportamento configurado - o produtor camel-sql, por exemplo, pega a instrução a executar de um cabeçalho Camel quando um está presente - portanto um cabeçalho injetado pode redirecionar o que uma etapa downstream na rota faz com dados que o autor da rota nunca pretendia que ela tirasse da mensagem. Quais sinks são alcançáveis e quais são as consequências depende inteiramente do que a rota faz após a etapa de unmarshal. O consumidor camel-mail já aplicava uma estratégia de filtro de cabeçalhos em seu próprio caminho de entrada, então este era o caminho de entrada paralelo para o mesmo componente que o endurecimento anterior não cobria. A cópia afetada só é alcançada quando headersInline está habilitado, o que não é o padrão: com a configuração padrão, os cabeçalhos MIME são apresentados como anexos em vez de cabeçalhos de mensagem, e não são afetados. O comportamento remonta à introdução do formato de dados na versão 2.17.0 e esteve presente em todas as linhas de versão até esta correção. Recomenda-se que os usuários atualizem para a versão 4.22.0, que corrige o problema. Se os usuários estiverem na linha de versões LTS 4.14.x, sugere-se que atualizem para 4.14.9. Se os usuários estiverem na linha de versões 4.18.x, sugere-se que atualizem para 4.18.4. Para implantações que não podem atualizar imediatamente, mantenha headersInline em seu valor padrão false onde os cabeçalhos inline não forem necessários, pois a cópia só é alcançada quando ele está habilitado. Onde ele precisar permanecer habilitado, remova os cabeçalhos internos do Camel imediatamente após a etapa de unmarshal, por exemplo com removeHeaders(“Camel*”) colocado antes de qualquer processador ou produtor que leia cabeçalhos de controle, e não faça unmarshal de conteúdo MIME de um remetente não confiável em uma rota que despache com base em valores de cabeçalho. Como defesa em profundidade, trate os nomes dos cabeçalhos de qualquer mensagem MIME que chegue de fora do limite de confiança como entrada não confiável.
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.