CVE-2026-78329

Resumo

Vulnerabilidade de validação de entrada inadequada no componente Undertow do Apache Camel. Este problema afeta o Apache Camel: de 4.11.0 antes de 4.14.9, de 4.15.0 antes de 4.18.4, de 4.19.0 antes de 4.22.0. O UndertowEndpoint definia por padrão seu campo headerFilterStrategy para a base HttpHeaderFilterStrategy e enviava essa instância para o UndertowHttpBinding que ele cria de forma lazy, sobrescrevendo o UndertowHeaderFilterStrategy que o DefaultUndertowHttpBinding instala em seu próprio construtor. A menos que uma implantação fornecesse um binding personalizado ou um headerFilterStrategy explícito, a filtragem específica do undertow, portanto, nunca era executada nas rotas configuradas no endpoint: o objeto da estratégia era construído e imediatamente substituído antes de poder ser consultado. A consequência é que o prefixo legado websocket. do cabeçalho Exchange não era filtrado no limite de transporte undertow em nenhuma das direções, então um consumidor HTTP undertow mapeava cabeçalhos de wire de entrada dessa forma para o Exchange, onde um produtor WebSocket undertow os lê como diretivas de despacho e pode ser induzido a entregar a um peer diferente daquele que a rota selecionou; e nomes de cabeçalho que o próprio undertow não aceita eram mapeados para o Exchange em vez de serem ignorados. Os consumidores do Rest DSL nunca foram afetados, porque o UndertowComponent atribui explicitamente o UndertowRestHeaderFilterStrategy, que estende a estratégia undertow. Isto não é uma regressão da CVE-2025-30177: a base HttpHeaderFilterStrategy configura o filtro de prefixo Camel de entrada por si só, então a proteção introduzida por esse advisory continuou funcionando por meio da classe base e nunca foi perdida. O que a mudança fez foi deixar a estratégia undertow órfã no caminho do endpoint, com o efeito de que duas correções subsequentes escritas nela — uma ignorando nomes de cabeçalho que o undertow rejeita, uma filtrando o prefixo legado websocket. em ambas as direções — foram aplicadas a uma classe que o endpoint não usava mais e nunca surtiram efeito nas versões em que foram lançadas. Recomenda-se que os usuários façam upgrade para a versão 4.22.0, que corrige o problema. Se os usuários estiverem no fluxo de versões LTS 4.14.x, sugere-se que façam upgrade para 4.14.9. Se os usuários estiverem no fluxo de versões 4.18.x, sugere-se que façam upgrade para 4.18.4. Para implantações que não podem atualizar imediatamente, configure a estratégia explicitamente em vez de depender do padrão, por exemplo, vinculando um UndertowHeaderFilterStrategy no registro e referenciando-o no endpoint como undertow:http://0.0.0.0:8080/foo?headerFilterStrategy=#myStrategy, e adicionalmente remova os cabeçalhos de despacho no limite de confiança com removeHeaders(“websocket.*”). Observe uma limitação residual que o upgrade não remove: o componente undertow mantém deliberadamente os valores websocket. como parte de seu contrato de API visível externamente, e o UndertowProducer os lê com in.getHeader, que não consulta um HeaderFilterStrategy de forma alguma. A filtragem restaurada é, portanto, defesa em profundidade apenas no limite de transporte undertow. Uma rota que transporta uma mensagem não confiável de um consumidor não-undertow para um produtor undertow não é protegida por esta correção e deve remover esses cabeçalhos por conta própria.