CVE-2026-78329 in Camel
Sumário
de VulDB • 25/08/2026
Vulnerabilidade de validação inadequada de entrada no componente Apache Camel Undertow.
Este problema afeta o Apache Camel: das versões 4.11.0 anteriores à 4.14.9, das versões 4.15.0 anteriores à 4.18.4 e das versões 4.19.0 anteriores à 4.22.0.
O UndertowEndpoint definia seu campo headerFilterStrategy como a classe base HttpHeaderFilterStrategy e enviava essa instância para o UndertowHttpBinding que ele cria de forma preguiçosa (lazy), sobrescrevendo o UndertowHeaderFilterStrategy que o DefaultUndertowHttpBinding instala em seu próprio construtor. A menos que um deployment fornecesse uma binding personalizada ou um headerFilterStrategy explícito, a filtragem específica do undertow nunca era executada nas rotas configuradas no endpoint: o objeto da estratégia era construído e imediatamente substituído antes de ser consultado. A consequência é que o prefixo legado websocket. Exchange-header não foi filtrado na fronteira do transporte undertow em nenhuma das direções, portanto um consumidor HTTP undertow mapeava cabeçalhos de entrada dessa forma para o Exchange, onde um produtor WebSocket undertow os lê como diretivas de dispatch e pode ser induzido a entregar a um peer diferente daquele selecionado pela rota; além disso, nomes de cabeçalho que o próprio undertow não aceita eram mapeados para o Exchange em vez de serem ignorados. Os consumidores Rest DSL nunca foram afetados, pois o UndertowComponent atribui explicitamente o UndertowRestHeaderFilterStrategy, que estende a estratégia do undertow. Esta não é uma regressão da CVE-2025-30177: a classe base HttpHeaderFilterStrategy configura o filtro de prefixo Camel de entrada por si só, portanto a proteção introduzida por aquele advisory continuou funcionando através da classe base e nunca foi perdida. O que a alteração fez foi deixar a estratégia do undertow órfã no caminho do endpoint, com o efeito de que duas correções subsequentes escritas nela — uma ignorando nomes de cabeçalho rejeitados pelo undertow e outra filtrando o prefixo legado websocket. em ambas as direções — foram aplicadas a uma classe que o endpoint já não utilizava e nunca tiveram efeito nas versões lançadas com elas.
Recomenda-se aos usuários atualizarem para a versão 4.22.0, que corrige o problema. Se os usuários estiverem na linha de releases LTS da série 4.14.x, sugere-se que atualizem para a 4.14.9. Se os usuários estiverem na linha de releases da série 4.18.x, sugere-se que atualizem para a 4.18.4. Para deployments que não podem atualizar imediatamente, configurem explicitamente a estratégia em vez de confiar no padrão, por exemplo, vinculando um UndertowHeaderFilterStrategy ao registry e referenciando-o no endpoint como undertow:http://0.0.0.0:8080/foo?headerFilterStrategy=#myStrategy, além de remover os cabeçalhos de dispatch na fronteira de confiança com removeHeaders("websocket.*"). Note uma limitação residual que a atualização não remove: o componente undertow mantém deliberadamente os valores websocket. como parte de seu contrato de API externamente visível, e o UndertowProducer lê esses valores com in.getHeader, que não consulta nenhuma HeaderFilterStrategy em absoluto. A filtragem restaurada é, portanto, defesa em profundidade apenas na fronteira do transporte undertow. Uma rota que transporta uma mensagem não confiável de um consumidor não-undertow para um produtor undertow não está protegida por esta correção e deve remover esses cabeçalhos por conta própria.
If you want to get best quality of vulnerability data, you may have to visit VulDB.