CVE-2026-71569

Resumo

Vulnerabilidade de Server-Side Request Forgery (SSRF) no componente A2A do Apache Camel. Este problema afeta o Apache Camel: de 4.21.0 até antes de 4.22.2. O WebhookUrlValidator classificava o host de um webhook de notificação push em dois locais que não concordavam entre si. Um host escrito como literal de IP era comparado com uma lista de prefixos de string que nomeava o intervalo local exclusivo IPv6 fc00::/7, enquanto um host alcançado por meio de um nome era resolvido e o endereço resultante classificado com os predicados InetAddress isLoopbackAddress, isAnyLocalAddress, isLinkLocalAddress e isSiteLocalAddress. Esses predicados não cobrem o mesmo terreno que a lista de prefixos: isSiteLocalAddress reporta o bloco obsoleto fec0::/10 e não os endereços locais exclusivos fc00::/7 que o substituíram, e o JDK não possui nenhum predicado para eles. O mesmo endereço era, portanto, aceito ou rejeitado dependendo de como era escrito, e uma URL de webhook cujo nome de host fosse resolvido para fc00::/7 passava por uma proteção que recusava o endereço idêntico fornecido como literal. O PushNotificationDispatcher então enviava a notificação push para esse endereço, juntamente com qualquer cabeçalho Authorization transportado na mesma configuração, cujo esquema e credenciais são fornecidos pelo chamador que registra. A URL do webhook chega como TaskPushNotificationConfig.url do chamador que registra a notificação push, portanto é controlada pelo atacante, e allowLocalWebhookUrls é false por padrão, que é a configuração na qual se espera que a proteção se mantenha. A resposta não é retransmitida de volta ao chamador que registrou a configuração, então o que a lacuna produz é uma requisição HTTPS de saída cega do processo Camel para um endereço interno que a proteção foi escrita para recusar; alcançar um serviço dessa forma exige adicionalmente que o nome seja resolvido para fc00::/7 no ambiente de destino, que um serviço HTTPS esteja escutando nesse endereço e que o handshake TLS seja bem-sucedido para o nome solicitado, razão pela qual a severidade é avaliada como média. A mesma pré-verificação de string também estava errada na direção oposta: ela comparava a string bruta do host sem primeiro estabelecer que o host era um literal de IP, então qualquer nome que apenas começasse com fc ou fd, como fcm.googleapis.com, era recusado de imediato. Recomenda-se que os usuários atualizem para a versão 4.23.0, que corrige o problema. Se os usuários estiverem no fluxo de releases 4.22.x, sugere-se que atualizem para 4.22.2. A linha de releases 4.21.x atingiu o fim de vida antes que este problema fosse resolvido e não receberá correção, portanto implantações nela devem migrar para uma release suportada. Tanto o caminho literal quanto o resolvido agora classificam o endereço a partir de seus bytes brutos com um único classificador compartilhado, que reconhece fc00::/7 e o espaço de endereçamento compartilhado 100.64.0.0/10, bem como endereços compatíveis com IPv4, NAT64 (64:ff9b::/96) e 6to4 (2002::/16) cujo endereço IPv4 embutido não é roteável globalmente. Para implantações que não podem atualizar imediatamente, coloque autenticação na frente do caminho de configuração de notificação push do A2A para que a URL do webhook não chegue de um chamador não confiável, e negue a saída do processo Camel para fc00::/7 no nível de rede; onde a implantação não tem necessidade de IPv6, iniciar a JVM com -Djava.net.preferIPv4Stack=true remove a classe de endereço da qual a lacuna depende. Observe que allowLocalWebhookUrls=false já é o padrão e não fecha a lacuna por si só.