CVE-2026-71569

Résumé

Vulnérabilité de falsification de requête côté serveur (SSRF) dans le composant A2A d'Apache Camel. Ce problème affecte Apache Camel : de 4.21.0 à avant 4.22.2. WebhookUrlValidator classifiait l'hôte d'un webhook de notification push à deux endroits qui ne concordaient pas. Un hôte écrit sous forme de littéral IP était comparé à une liste de préfixes de chaînes désignant la plage locale unique IPv6 fc00::/7, tandis qu'un hôte atteint via un nom était résolu et l'adresse résultante classifiée avec les prédicats InetAddress isLoopbackAddress, isAnyLocalAddress, isLinkLocalAddress et isSiteLocalAddress. Ces prédicats ne couvrent pas le même terrain que la liste de préfixes : isSiteLocalAddress signale le bloc obsolète fec0::/10 et non les adresses locales uniques fc00::/7 qui l'ont remplacé, et le JDK ne dispose d'aucun prédicat pour celles-ci. La même adresse était donc acceptée ou rejetée selon la façon dont elle était écrite, et une URL de webhook dont le nom d'hôte se résolvait dans fc00::/7 passait un garde-fou qui refusait l'adresse identique fournie sous forme de littéral. PushNotificationDispatcher envoyait ensuite la notification push à cette adresse, accompagnée de tout en-tête Authorization porté par la même configuration, dont le schéma et les identifiants sont fournis par l'appelant enregistreur. L'URL du webhook arrive sous la forme TaskPushNotificationConfig.url depuis l'appelant qui enregistre la notification push ; elle est donc contrôlée par l'attaquant, et allowLocalWebhookUrls vaut false par défaut, ce qui est la configuration dans laquelle le garde-fou est censé tenir. La réponse n'est pas relayée à l'appelant qui a enregistré la configuration, de sorte que ce que la faille produit est une requête HTTPS sortante aveugle depuis le processus Camel vers une adresse interne que le garde-fou était censé refuser ; atteindre un service de cette manière exige en outre que le nom se résolve dans fc00::/7 dans l'environnement cible, qu'un service HTTPS écoute sur cette adresse et que la poignée de main TLS réussisse pour le nom demandé, ce qui explique que la gravité soit évaluée comme moyenne. La même pré-vérification de chaîne était également erronée dans l'autre sens : elle comparait la chaîne d'hôte brute sans d'abord établir que l'hôte était un littéral IP, si bien que tout nom commençant simplement par fc ou fd, comme fcm.googleapis.com, était refusé d'emblée. Il est recommandé aux utilisateurs de mettre à niveau vers la version 4.23.0, qui corrige le problème. Si les utilisateurs sont sur la branche des versions 4.22.x, il leur est suggéré de mettre à niveau vers 4.22.2. La ligne de versions 4.21.x a atteint sa fin de vie avant que ce problème ne soit résolu et ne recevra pas de correctif ; les déploiements sur cette ligne doivent donc migrer vers une version prise en charge. Le chemin littéral comme le chemin résolu classifient désormais l'adresse à partir de ses octets bruts avec un classificateur unique partagé, qui reconnaît fc00::/7 et l'espace d'adressage partagé 100.64.0.0/10, ainsi que les adresses compatibles IPv4, NAT64 (64:ff9b::/96) et 6to4 (2002::/16) dont l'adresse IPv4 intégrée n'est pas routable globalement. Pour les déploiements qui ne peuvent pas être mis à niveau immédiatement, placez une authentification devant le chemin de configuration des notifications push A2A afin que l'URL du webhook n'arrive pas d'un appelant non fiable, et refusez l'égress depuis le processus Camel vers fc00::/7 au niveau du réseau ; lorsque le déploiement n'a pas besoin d'IPv6, démarrer la JVM avec -Djava.net.preferIPv4Stack=true supprime la classe d'adresses sur laquelle repose la faille. Notez que allowLocalWebhookUrls=false est déjà la valeur par défaut et ne comble pas à lui seul la faille.