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 establecía por defecto su campo headerFilterStrategy en la clase base HttpHeaderFilterStrategy y colocaba esa instancia en el UndertowHttpBinding que crea de forma diferida, sobrescribiendo el UndertowHeaderFilterStrategy que DefaultUndertowHttpBinding instala en su propio constructor. A menos que un despliegue proporcionara un binding personalizado o un headerFilterStrategy explícito, el filtrado específico de undertow, por tanto, nunca se ejecutaba en las rutas configuradas en el endpoint: el objeto de la estrategia se construía e inmediatamente se reemplazaba antes de que pudiera ser consultado. La consecuencia es que el prefijo heredado websocket. de los encabezados del Exchange no se filtraba en el límite del transporte undertow en ninguna dirección, por lo que un consumidor HTTP undertow mapeaba los encabezados de cable entrantes de esa forma en el Exchange, donde un productor WebSocket undertow los lee como directivas de despacho y puede ser manipulado para entregar a un par distinto del que la ruta seleccionó; y los nombres de encabezado que el propio undertow no acepta se mapeaban en el Exchange en lugar de omitirse. Los consumidores de Rest DSL nunca se vieron afectados, porque UndertowComponent asigna explícitamente UndertowRestHeaderFilterStrategy, que extiende la estrategia de undertow. Esto no es una regresión de CVE-2025-30177: la clase base HttpHeaderFilterStrategy configura por sí misma el filtro entrante de prefijo Camel, por lo que la protección introducida por ese aviso siguió 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 que omite los nombres de encabezado que undertow rechaza, y otra que filtra el prefijo heredado websocket. en ambas direcciones — se aplicaron a una clase que el endpoint ya no usaba y nunca surtieron efecto en las versiones en las que se publicaron. 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, se les sugiere actualizar a 4.14.9. Si los usuarios están en la rama de versiones 4.18.x, se les sugiere actualizar a 4.18.4. Para los despliegues que no puedan actualizar de inmediato, configure la estrategia explícitamente en lugar de depender de la predeterminada, por ejemplo, vinculando un UndertowHeaderFilterStrategy en el registro y referenciándolo en el endpoint como undertow:http://0.0.0.0:8080/foo?headerFilterStrategy=#myStrategy, y además elimine los encabezados 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 en absoluto una HeaderFilterStrategy. Por lo tanto, el filtrado restaurado es solo defensa en profundidad en el límite del transporte undertow. Una ruta que transporte un mensaje no confiable desde un consumidor no undertow hacia un productor undertow no está protegida por esta corrección y debe eliminar esos encabezados por sí misma.