CVE-2026-71569

Resumen

Vulnerabilidad de Server-Side Request Forgery (SSRF) en el componente A2A de Apache Camel. Este problema afecta a Apache Camel: desde 4.21.0 hasta antes de 4.22.2. WebhookUrlValidator clasificaba el host de un webhook de notificación push en dos lugares que no coincidían. Un host escrito como literal de IP se comparaba con una lista de prefijos de cadena que nombraba el rango local único de IPv6 fc00::/7, mientras que un host alcanzado a través de un nombre se resolvía y la dirección resultante se clasificaba con los predicados de InetAddress isLoopbackAddress, isAnyLocalAddress, isLinkLocalAddress e isSiteLocalAddress. Esos predicados no cubren el mismo terreno que la lista de prefijos: isSiteLocalAddress informa del bloque obsoleto fec0::/10 y no de las direcciones locales únicas fc00::/7 que lo reemplazaron, y el JDK no incluye ningún predicado para ellas en absoluto. Por lo tanto, la misma dirección se aceptaba o se rechazaba según cómo estuviera escrita, y una URL de webhook cuyo nombre de host se resolvía en fc00::/7 pasaba una comprobación que rechazaba la dirección idéntica dada como literal. PushNotificationDispatcher enviaba entonces la notificación push a esa dirección, junto con cualquier cabecera Authorization incluida en la misma configuración, cuyo esquema y credenciales proporciona el llamador que la registra. La URL del webhook llega como TaskPushNotificationConfig.url desde el llamador que registra la notificación push, por lo que está controlada por el atacante, y allowLocalWebhookUrls es false por defecto, que es la configuración en la que se espera que la comprobación se mantenga. La respuesta no se retransmite de vuelta al llamador que registró la configuración, por lo que lo que produce la brecha es una solicitud HTTPS saliente ciega desde el proceso de Camel hacia una dirección interna que la comprobación estaba escrita para rechazar; alcanzar un servicio de esa manera requiere además que el nombre se resuelva en fc00::/7 en el entorno objetivo, que haya un servicio HTTPS escuchando en esa dirección y que el handshake TLS tenga éxito para el nombre solicitado, razón por la cual la severidad se evalúa como media. La misma comprobación previa de cadena también era errónea en la dirección opuesta: comparaba la cadena de host sin establecer primero que el host fuera un literal de IP, por lo que cualquier nombre que simplemente comenzara por fc o fd, como fcm.googleapis.com, se rechazaba de plano. Se recomienda a los usuarios actualizar a la versión 4.23.0, que corrige el problema. Si los usuarios están en la línea de versiones 4.22.x, se sugiere que actualicen a 4.22.2. La línea de versiones 4.21.x alcanzó el fin de su ciclo de vida antes de que se resolviera este problema y no recibirá una corrección, por lo que las implementaciones en ella deben pasar a una versión compatible. Tanto la ruta del literal como la de la resolución ahora clasifican la dirección a partir de sus bytes sin procesar con un único clasificador compartido, que reconoce fc00::/7 y el espacio de direcciones compartido 100.64.0.0/10, así como direcciones compatibles con IPv4, NAT64 (64:ff9b::/96) y 6to4 (2002::/16) cuya dirección IPv4 incrustada no es enrutable globalmente. Para las implementaciones que no pueden actualizar de inmediato, coloque autenticación delante de la ruta de configuración de notificaciones push de A2A para que la URL del webhook no llegue desde un llamador no confiable, y deniegue la salida desde el proceso de Camel hacia fc00::/7 a nivel de red; cuando la implementación no necesite IPv6, iniciar la JVM con -Djava.net.preferIPv4Stack=true elimina la clase de dirección sobre la que gira la brecha. Tenga en cuenta que allowLocalWebhookUrls=false ya es el valor predeterminado y no cierra la brecha por sí solo.