CVE-2026-78329

Resumen

Vulnerabilidad de validación de entrada incorrecta en el componente Undertow de Apache Camel. Este problema afecta a Apache Camel: desde 4.11.0 antes de 4.14.9, desde 4.15.0 antes de 4.18.4, desde 4.19.0 antes de 4.22.0. UndertowEndpoint estableció por defecto su campo headerFilterStrategy a la HttpHeaderFilterStrategy base y empujó esa instancia en el UndertowHttpBinding que crea de forma perezosa, sobrescribiendo la UndertowHeaderFilterStrategy que DefaultUndertowHttpBinding instala en su propio constructor. A menos que una implementación suministrara un binding personalizado o una headerFilterStrategy explícita, el filtrado específico de undertow, por lo tanto, nunca se ejecutó en rutas configuradas por el endpoint: el objeto de estrategia fue construido e inmediatamente reemplazado antes de que pudiera ser consultado. La consecuencia es que el prefijo de cabecera de intercambio websocket. heredado no fue filtrado en el límite de transporte de undertow en ninguna dirección, por lo que un consumidor HTTP de undertow mapeó las cabeceras de cable entrantes de esa forma en el Exchange, donde un productor WebSocket de undertow las lee como directivas de despacho y puede ser hecho para entregarlas a un par diferente al seleccionado por la ruta; y los nombres de cabecera que undertow mismo no acepta fueron mapeados en el Exchange en lugar de ser omitidos. Los consumidores de Rest DSL nunca se vieron afectados, porque UndertowComponent asigna UndertowRestHeaderFilterStrategy explícitamente, que extiende la estrategia de undertow. Esto no es una regresión de CVE-2025-30177: la HttpHeaderFilterStrategy base configura el filtro de prefijo Camel entrante en sí misma, por lo que la protección introducida por ese aviso continuó funcionando a través de la clase base y nunca se perdió. Lo que hizo el cambio fue dejar la estrategia de undertow huérfana en la ruta del endpoint, con el efecto de que dos correcciones posteriores escritas en ella - una omitiendo nombres de cabecera que undertow rechaza, una filtrando el prefijo websocket. heredado en ambas direcciones - fueron aplicadas a una clase que el endpoint ya no usaba y nunca tuvieron efecto en las versiones que las incluyeron. Se recomienda a los usuarios actualizar a la versión 4.22.0, que corrige el problema. Si los usuarios están en la rama de versiones LTS 4.14.x, entonces se les sugiere actualizar a 4.14.9. Si los usuarios están en la rama de versiones 4.18.x, entonces se les sugiere actualizar a 4.18.4. Para implementaciones que no pueden actualizarse inmediatamente, configure la estrategia explícitamente en lugar de depender de la predeterminada, por ejemplo, vinculando una UndertowHeaderFilterStrategy en el registro y referenciándola en el endpoint como undertow:http://0.0.0.0:8080/foo?headerFilterStrategy=#myStrategy, y adicionalmente elimine las cabeceras de despacho en el límite de confianza con removeHeaders('websocket.*'). Tenga en cuenta una limitación residual que la actualización no elimina: el componente undertow mantiene deliberadamente los valores websocket. como parte de su contrato de API visible externamente, y UndertowProducer los lee con in.getHeader, que no consulta ninguna HeaderFilterStrategy en absoluto. El filtrado restaurado es, por lo tanto, una defensa en profundidad solo en el límite de transporte de undertow. Una ruta que transporta un mensaje no confiable desde un consumidor que no es de undertow a un productor de undertow no está protegida por esta corrección y debe eliminar esas cabeceras por sí misma.

Fuentes

• CVE-2026-78329PoC

  Reproductor de prueba de concepto para la omisión del filtro de cabeceras camel-undertow de Apache Camel (CVE-2026-78329), que demuestra la inyección de cabeceras websocket.* y proporciona detalles de las versiones afectadas y verificación de la corrección.