Instituto Nacional de ciberseguridad. Sección Incibe

017 - Ir a la línea de ayuda en Ciberseguridad    Ir a Agenda     Ir a Sala de prensa     Ir a suscripción de boletines

Boletín de vulnerabilidades

Vulnerabilidades con productos recientemente documentados:

No hay vulnerabilidades nuevas para los productos a los que está suscrito.



Otras vulnerabilidades de los productos a los que usted está suscrito, y cuya información ha sido actualizada recientemente:

  • Vulnerabilidad en HTTP Netty de Apache Camel (CVE-2026-49365)
    Severidad: MEDIA
    Fecha de publicación: 06/07/2026
    Fecha de última actualización: 09/07/2026
    Vulnerabilidad relacionada con la generación de mensajes de error que contienen información confidencial en el componente HTTP Netty de Apache Camel. El consumidor del servidor HTTP camel-netty-http 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. Esta opción tenía como valor predeterminado false porque el campo subyacente era un valor booleano primitivo no inicializado (el valor predeterminado de Java es false), mientras que los demás componentes del servidor HTTP de Camel (camel-http, camel-jetty, camel-servlet y camel-platform-http) lo establecen por defecto en 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 (a través de DefaultNettyHttpBinding), en lugar de devolver un cuerpo vacío. 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— recibirá, por lo tanto, 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 de clases, y la estructura interna de la aplicación, que un atacante puede utilizar para planear nuevos ataques. 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. En el caso de las implementaciones que no puedan actualizarse de inmediato, establezca explícitamente `muteException=true` en el consumidor camel-netty-http (por ejemplo, `netty-http: http://0.0.0.0:8080/api?muteException=true`, o de forma global mediante la propiedad `camel.component.netty-http.configuration.mute-exception=true`), de modo que los errores de procesamiento ya no devuelvan el seguimiento de la pila al cliente.
  • Vulnerabilidad en Keycloak de Apache Camel (CVE-2026-53913)
    Severidad: CRÍTICA
    Fecha de publicación: 06/07/2026
    Fecha de última actualización: 09/07/2026
    Vulnerabilidad por autenticación incorrecta, falta de autenticación para funciones críticas y fallo de seguridad (Failing Open) en el componente Keycloak de Apache Camel. La política KeycloakSecurityPolicy de camel-keycloak protege una ruta ejecutando KeycloakSecurityProcessor.beforeProcess(), que realiza tres comprobaciones en secuencia: rechaza una solicitud que no incluya un token de acceso; a continuación, solo si requiredRoles no está vacío, valida los roles; y, solo si requiredPermissions no está vacío, valida los permisos. La verificación criptográfica propiamente dicha del token de acceso de portador (firma, emisor y fecha de caducidad para un JWT local, o estado activo y emisor para la introspección del token) se lleva a cabo exclusivamente dentro de esas comprobaciones de roles y permisos. KeycloakSecurityPolicy establece por defecto requiredRoles y requiredPermissions como vacíos —lo que constituye la configuración básica documentada—, por lo que, en una ruta configurada de ese modo, se omiten las comprobaciones de roles y permisos y, por lo tanto, el token de acceso nunca se verifica. La comprobación de presencia del token sigue rechazando un token ausente, pero se acepta un token no válido: cualquier valor distinto de nulo en el encabezado Authorization: Bearer —incluida una cadena arbitraria o un JWT falsificado y sin firmar— supera la política y la solicitud llega a la ruta protegida, sin que se comprueben la firma, el emisor o la fecha de caducidad, y sin que se envíe ninguna solicitud a Keycloak. El token se lee del encabezado de la solicitud entrante porque allowTokenFromHeader tiene por defecto el valor «true». Dado que la razón habitual para situar una ruta detrás de esta política es que dicha ruta realice tareas del lado del servidor, esta omisión da lugar a un acceso no autenticado a dichas tareas; cuando la ruta protegida reenvía a un productor capaz de ejecutar código, puede dar lugar a la ejecución remota de código sin autenticación. Este defecto es independiente de CVE-2026-23552: ese problema se refería a la reclamación del emisor y se solucionó añadiendo una comprobación dentro de la rutina de verificación, pero en este caso no se llega en absoluto a la rutina de verificación en la configuración por defecto, por lo que el defecto persiste. Este problema afecta a Apache Camel: desde la versión 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 4.18.x, se les sugiere que actualicen a la 4.18.3. En el caso de las implementaciones que no puedan actualizarse de inmediato, configure un requiredRoles o requiredPermissions no vacío en cada KeycloakSecurityPolicy para que se ejecute la ruta de verificación del token, establezca allowTokenFromHeader en false cuando no se espere que el token provenga del encabezado de la solicitud, o realice la verificación del token en la capa del marco de trabajo antes de la política.
  • Vulnerabilidad en Atmosphere WebSocket (CVE-2026-55993)
    Severidad: ALTA
    Fecha de publicación: 06/07/2026
    Fecha de última actualización: 09/07/2026
    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 Atmosphere WebSocket. El consumidor camel-atmosphere-websocket asignaba los parámetros de consulta de WebSocket entrantes al mapa de encabezados de Camel Exchange sin aplicar ninguna HeaderFilterStrategy (WebsocketConsumer.sendEventNotification() recorre el mapa de cadenas de consulta recopilado en WebsocketConsumer.service() y copia cada entrada en el Exchange). Dado que nada bloqueaba el espacio de nombres de encabezados de Camel, un cliente que se conectara al punto final de WebSocket podía establecer encabezados de control internos de Camel —incluido CamelHttpUri (Exchange.HTTP_URI)— simplemente proporcionándolos como parámetros de consulta. En una ruta en la que el consumidor WebSocket 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. Cuando el punto final de WebSocket está expuesto sin autenticación, un atacante remoto no autenticado puede acceder a él. 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. La corrección hace que el consumidor aplique la estrategia HeaderFilterStrategy que ya hereda de la pila HTTP/servlet, filtrando 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 las 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), exija la autenticación en el punto final de WebSocket y evite conectar un consumidor no fiable directamente a un productor HTTP cuyo URI de destino pueda determinarse a partir de los encabezados del mensaje.
  • Vulnerabilidad en Iggy (CVE-2026-55994)
    Severidad: ALTA
    Fecha de publicación: 06/07/2026
    Fecha de última actualización: 09/07/2026
    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.
  • CVE-2026-56139
    Severidad: MEDIA
    Fecha de publicación: 06/07/2026
    Fecha de última actualización: 09/07/2026
    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.