Vulnerabilidades

*** Pendiente de traducción *** Improper Input Validation vulnerability in Apache Camel.<br /> <br /> This issue affects Apache Camel: from 4.8.0 through 4.18.2, from 4.19.0 through 4.20.0.<br /> <br /> Users are recommended to upgrade to version 4.18.3, 4.21.0, which fixes the issue.

*** Pendiente de traducción *** Improper Input Validation vulnerability in Apache Camel.<br /> <br /> This issue affects Apache Camel: through 4.14.7, from 4.15.0 through 4.18.2, from 4.19.0 through 4.20.0.<br /> <br /> Users are recommended to upgrade to version 4.14.8, 4.18.3, 4.21.0, which fixes the issue.

*** Pendiente de traducción *** Improper Input Validation vulnerability in Apache Camel.<br /> <br /> This issue affects Apache Camel: through 4.14.7, from 4.15.0 through 4.18.2, from 4.19.0 through 4.20.0.<br /> <br /> Users are recommended to upgrade to version 4.14.8, 4.18.3, 4.21.0, which fixes the issue.

*** Pendiente de traducción *** Missing filtering when the helmRepoURLRegex field isn&amp;#39;t set on a GitRepo resource in SUSE Rancher Fleet&amp;#39;s bundle reader in 0.15 before 0.15.2, 0.14 before 0.14.6, 0.13 before 0.13.11 and 0.12 before 0.12.15 forwards Helm authentication credentials (BasicAuth) to any URL specified in the helm.repo field of a fleet.yaml file, allowing attackers able to push to fleet monitored git repos to leak helm access credentials.

*** Pendiente de traducción *** Potential forgery of webhook requests when using a unauthenticated webhook in SUSE Rancher Fleet 0.15 before 0.15.2, 0.14 before 0.14.6, 0.13 before 0.13.11 and 0.12 before 0.12.5 could be used by remote attackers to cause a denial of service or a downgrade attack on other repositories on the system.

*** Pendiente de traducción *** An authenticated user could manipulate a company ID parameter in a POST request to the backend to gain unauthorised access to other companies hosted within the same subdomain environment. The application does not adequately verify whether the requested company ID belongs to the authenticated user’s session, resulting in a cross-tenant authorisation bypass. If this vulnerability is successfully exploited, it allows unauthorised access to sensitive customer information, including billing data, and may enable the unauthorised modification of third-party data.

*** Pendiente de traducción *** The software accepts user-supplied input via a URL parameter without adequate output encoding before reflecting it back to the user&amp;#39;s browser. This condition allows an attacker to inject malicious script content into pages served by the application.<br /> <br /> By leveraging this weakness, an attacker can cause the user&amp;#39;s browser to redirect to a malicious website, modify the UI of the webpage, or retrieve information from the browser. However, the impact is mitigated by the use of httpOnly flags on session-related cookies, preventing session hijacking.

Se ha detectado una vulnerabilidad en Red Hat Advanced Cluster Security para Kubernetes (RHACS). Central no limita la profundidad de las consultas GraphQL que se sirven en la API GraphQL autenticada. Un usuario autenticado con un token de API válido puede enviar consultas profundamente anidadas que provocan un consumo excesivo de recursos en Central, lo que da lugar a una denegación de servicio en el plano de gestión.

Vulnerabilidad por validación incorrecta de entradas en el componente AWS SNS de Apache Camel. El componente «camel-aws2-sns» filtra los encabezados de Camel mediante una estrategia de filtrado de encabezados específica del componente, «Sns2HeaderFilterStrategy». Al igual que su homólogo Sqs2HeaderFilterStrategy, originalmente solo configuraba un filtro de salida (setOutFilterPattern, que impide que se escriban los encabezados Camel*, breadcrumbId y org.apache.camel.*) y no configuraba ninguna regla de filtro de entrada. En el caso del componente relacionado camel-aws2-sqs, esta laguna en el filtrado de entrada era explotable, ya que Sqs2Consumer mapea los atributos de los mensajes SQS entrantes al Camel Exchange mediante HeaderFilterStrategy.applyFilterToExternalHeaders, lo que permite al remitente de un mensaje inyectar encabezados de control de Camel (registrado como CVE-2026-46456). camel-aws2-sns, por el contrario, es exclusivamente de productor: Sns2Endpoint no admite consumidores (createConsumer lanza una excepción UnsupportedOperationException, «No se pueden recibir mensajes desde este punto final»), por lo que ningún atributo de mensaje proporcionado externamente se asigna nunca en la entrada a un Camel Exchange a través de SNS, y, por lo tanto, la regla de filtro de entrada que faltaba en Sns2HeaderFilterStrategy no era accesible para un atacante. Como parte de la misma corrección (CAMEL-23506), se ha añadido una regla de filtro de entrada (setInFilterStartsWith para el espacio de nombres Camel) a Sns2HeaderFilterStrategy, de modo que su configuración coincida con la de Sqs2HeaderFilterStrategy, ya corregida, y con la de las demás estrategias equivalentes. Se trata de una medida de defensa en profundidad sin ninguna vía de explotación conocida en camel-aws2-sns. Este problema afecta a Apache Camel: desde la versión 4.0.0 hasta la 4.14.8, desde la 4.15.0 hasta la 4.18.3 y desde la 4.19.0 hasta la 4.21.0. Se trata de un cambio de refuerzo de la defensa en profundidad sin vías de explotación conocidas en camel-aws2-sns, que es de solo productor, por lo que no se requiere ninguna acción urgente ni solución alternativa. Los usuarios que deseen que el comportamiento se ajuste a lo previsto pueden actualizar a la versión 4.21.0, o a la 4.14.8 en la rama de versiones LTS 4.14.x, o a la 4.18.3 en la rama de versiones 4.18.x, que incluyen el cambio. Como buena práctica general, los operadores deben seguir aplicando permisos IAM de «privilegio mínimo» a sus temas de SNS.

Vulnerabilidad relacionada con la generación de mensajes de error que contienen información confidencial en el componente Apache Camel Undertow. El consumidor del servidor HTTP camel-undertow expone una opción denominada muteException que controla lo que se devuelve al cliente cuando se produce un error en el procesamiento de una ruta. El valor predeterminado de esta opción es false, mientras que en los demás componentes del servidor HTTP de Camel (camel-http, camel-jetty, camel-servlet y camel-platform-http) el valor predeterminado es true. Con muteException=false, cuando una solicitud provoca una excepción durante el procesamiento de la ruta, el consumidor escribe el seguimiento completo de la pila de Throwable en el cuerpo de la respuesta HTTP como text/plain, en lugar de devolver un cuerpo vacío. Por lo tanto, cualquier cliente no autenticado que pueda acceder al punto final y provocar un error de procesamiento —por ejemplo, enviando un cuerpo de solicitud mal formado, un parámetro no válido o provocando de cualquier otra forma un fallo interno de la ruta— recibe un seguimiento completo de la pila de Java. Dicha traza de pila puede revelar información interna confidencial, incluidas credenciales incrustadas en los mensajes de excepción, nombres de host internos y direcciones IP, rutas del sistema de archivos, detalles de dependencias y versiones, nombres de bases de datos y clases, y la estructura interna de la aplicación, que un atacante puede utilizar para planear nuevos ataques. Además, para los usuarios de Rest DSL, la opción `muteException` no se respetaba en absoluto: el `RestUndertowHttpBinding` se creaba con un valor false codificado de forma fija, por lo que se devolvía el seguimiento de la pila incluso cuando se había configurado `muteException=true`. Este problema afecta a Apache Camel: desde la versión 4.0.0 hasta la 4.14.8, desde la 4.15.0 hasta la 4.18.3 y desde la 4.19.0 hasta la 4.21.0. Se recomienda a los usuarios que actualicen a la versión 4.21.0, que corrige el problema. Si los usuarios utilizan la rama de versiones LTS 4.14.x, se les recomienda actualizar a la versión 4.14.8. Si utilizan la rama de versiones 4.18.x, se les recomienda actualizar a la versión 4.18.3. En el caso de implementaciones que no puedan actualizarse de inmediato, se debe establecer explícitamente muteException=true en el consumidor camel-undertow (por ejemplo, undertow: http://0.0.0.0:8080/api?muteException=true, o de forma global mediante la propiedad camel.component.undertow.mute-exception=true), de modo que los errores de procesamiento ya no devuelvan el seguimiento de la pila al cliente; ten en cuenta que, en las versiones afectadas, esta solución provisional no se aplica a los consumidores de Rest DSL, cuyo enlace ignora la opción hasta que se aplique la corrección.

Validación incorrecta de entradas, exposición de información confidencial a un agente no autorizado y vulnerabilidad de falsificación de solicitudes del lado del servidor (SSRF) en Apache Camel, en el componente Iggy. El consumidor «camel-iggy» asignaba los encabezados de usuario de los mensajes entrantes de Iggy al mapa de encabezados de Camel Exchange sin aplicar ninguna estrategia de filtrado de encabezados (HeaderFilterStrategy); IggyFetchRecords copiaba los encabezados de usuario del mensaje directamente en el Exchange. Dado que nada bloqueaba el espacio de nombres de encabezados de Camel, un actor capaz de publicar en el flujo o tema de Iggy consumido podía establecer encabezados de control internos de Camel —incluido CamelHttpUri (Exchange.HTTP_URI)— simplemente proporcionándolos como encabezados de usuario del mensaje. En una ruta en la que el consumidor de Iggy alimenta a un productor HTTP posterior, el CamelHttpUri inyectado redirige la solicitud HTTP del lado del servidor a un destino elegido por el atacante (falsificación de solicitudes del lado del servidor; por ejemplo, a un servicio interno o a un punto final de metadatos en la nube). Además, el productor HTTP resuelve los marcadores de posición de propiedades de Camel en la URI resultante (controlada por el atacante), por lo que los marcadores de posición incrustados en el valor inyectado —como una referencia a una variable de entorno, una propiedad de la aplicación o una referencia al almacén de secretos— se resuelven a sus valores reales y se envían al atacante, revelando variables de entorno, propiedades de la aplicación y secretos del almacén. Este problema afecta a Apache Camel: desde la versión 4.17.0 hasta la 4.18.3, y desde la 4.19.0 hasta la 4.21.0. Se recomienda a los usuarios que actualicen a la versión 4.21.0, que corrige el problema. Si los usuarios se encuentran en la rama de versiones 4.18.x, se les sugiere que actualicen a la 4.18.3. La corrección añade una IggyHeaderFilterStrategy específica (y una opción de punto final headerFilterStrategy) que filtra el espacio de nombres de los encabezados de Camel sin distinguir entre mayúsculas y minúsculas en la asignación de entrada, de modo que los encabezados Camel* / camel* proporcionados externamente ya no se copian en el Exchange. En el caso de implementaciones que no puedan actualizarse de inmediato, elimine los encabezados de control de Camel del mensaje entrante antes de que lleguen a cualquier productor posterior (por ejemplo, utilice removeHeaders(“Camel*”) y removeHeaders(“camel*”) al inicio de la ruta), restrinja quién puede publicar en el flujo o tema de Iggy consumido y evite conectar a un consumidor no fiable directamente a un productor HTTP cuyo URI de destino pueda determinarse a partir de los encabezados del mensaje.

Vulnerabilidad por validación inadecuada de entradas y neutralización incorrecta de elementos especiales en la salida utilizada por un componente posterior (inyección) en el componente Apache Camel Kafka. El productor camel-kafka puede anular el tema de destino configurado en tiempo de ejecución a través del encabezado kafka.OVERRIDE_TOPIC de Exchange: KafkaProducer.evaluateTopic() devuelve el valor del encabezado en lugar del tema configurado en el punto final. Las constantes de los encabezados de control en KafkaConstants (por ejemplo, OVERRIDE_TOPIC = kafka.OVERRIDE_TOPIC, OVERRIDE_TIMESTAMP = kafka.OVERRIDE_TIMESTAMP, PARTITION_KEY = kafka. PARTITION_KEY) utilizan valores simples, sin prefijo Camel. La propia estrategia KafkaHeaderFilterStrategy de camel-kafka filtra el espacio de nombres kafka.*, pero solo en el límite de serialización de Kafka a Exchange (al leer los encabezados de los registros de Kafka en Exchange y al escribir los encabezados de Exchange en un registro de Kafka); no se aplica a los encabezados que llegan desde un consumidor anterior en una ruta de múltiples componentes. El consumidor HTTP anterior utiliza HttpHeaderFilterStrategy, que solo bloquea el espacio de nombres Camel / camel, por lo que un encabezado kafka.* pasa sin ser filtrado. Como resultado, en una ruta que conecta un consumidor HTTP (por ejemplo, platform-http) con un productor kafka:, cualquier cliente HTTP podría establecer el encabezado kafka.OVERRIDE_TOPIC y provocar que el mensaje se publique en un tema de Kafka arbitrario en lugar del configurado, redirigiéndolo a un tema interno sensible o inyectando mensajes creados por un atacante en un tema consumido por un servicio crítico posterior. Los encabezados relacionados kafka.OVERRIDE_TIMESTAMP y kafka.PARTITION_KEY también podrían inyectarse para antedatar mensajes o dirigirlos a particiones específicas. No se requieren credenciales cuando el consumidor puente no está autenticado. Este problema afecta a Apache Camel: desde la versión 4.0.0 hasta la 4.14.8, desde la 4.15.0 hasta la 4.18.3 y desde la 4.19.0 hasta la 4.21.0. Se recomienda a los usuarios que actualicen a la versión 4.21.0, que corrige el problema. Si los usuarios utilizan las versiones LTS de la rama 4.14.x, se les sugiere que actualicen a la 4.14.8. Si los usuarios utilizan las versiones de la rama 4.18.x, se les sugiere que actualicen a la 4.18.3. Tras la actualización, las rutas que establezcan o lean encabezados de Kafka mediante los nombres de encabezado sin formato deben utilizar los nombres CamelKafka* (por ejemplo, CamelKafkaOverrideTopic y CamelKafkaTopic) en lugar de los antiguos valores kafka.*. En el caso de las implementaciones que no puedan actualizarse de inmediato, elimine los encabezados «kafka.*» de cualquier entrada no fiable antes del productor kafka: (por ejemplo, removeHeaders(“kafka.*”) al inicio de la ruta) y establezca el tema de destino a partir de una fuente fiable.