CVE-2026-71569

Riepilogo

Vulnerabilità Server-Side Request Forgery (SSRF) nel componente A2A di Apache Camel. Il problema riguarda Apache Camel: dalla 4.21.0 alla 4.22.2 esclusa. WebhookUrlValidator classificava l'host di un webhook di notifica push in due punti che non concordavano. Un host scritto come IP letterale veniva confrontato con un elenco di prefissi di stringa che indicavano l'intervallo locale univoco IPv6 fc00::/7, mentre un host raggiunto tramite un nome veniva risolto e l'indirizzo risultante classificato con i predicati InetAddress isLoopbackAddress, isAnyLocalAddress, isLinkLocalAddress e isSiteLocalAddress. Tali predicati non coprono lo stesso terreno dell'elenco di prefissi: isSiteLocalAddress segnala il blocco deprecato fec0::/10 e non gli indirizzi locali univoci fc00::/7 che lo hanno sostituito, e il JDK non dispone di alcun predicato per questi ultimi. Lo stesso indirizzo veniva quindi accettato o rifiutato a seconda di come era scritto, e un URL di webhook il cui nome host si risolveva in fc00::/7 superava un controllo che rifiutava l'identico indirizzo fornito come letterale. PushNotificationDispatcher inviava quindi la notifica push a quell'indirizzo, insieme a qualsiasi header Authorization presente nella stessa configurazione, il cui schema e le cui credenziali sono forniti dal chiamante che effettua la registrazione. L'URL del webhook arriva come TaskPushNotificationConfig.url dal chiamante che registra la notifica push, quindi è controllato dall'attaccante, e allowLocalWebhookUrls è false per impostazione predefinita, che è la configurazione in cui ci si aspetta che il controllo tenga. La risposta non viene ritrasmessa al chiamante che ha registrato la configurazione, quindi ciò che la lacuna produce è una richiesta HTTPS in uscita cieca dal processo Camel verso un indirizzo interno che il controllo era stato scritto per rifiutare; raggiungere un servizio in questo modo richiede inoltre che il nome si risolva in fc00::/7 nell'ambiente di destinazione, che un servizio HTTPS sia in ascolto su quell'indirizzo e che l'handshake TLS riesca per il nome richiesto, motivo per cui la gravità è valutata media. Lo stesso pre-controllo sulla stringa era errato anche nella direzione opposta: confrontava la stringa host grezza senza prima stabilire che l'host fosse un IP letterale, quindi qualsiasi nome che iniziava semplicemente con fc o fd, come fcm.googleapis.com, veniva rifiutato senza appello. Si raccomanda agli utenti di aggiornare alla versione 4.23.0, che corregge il problema. Se gli utenti si trovano sul ramo di release 4.22.x, si suggerisce di aggiornare alla 4.22.2. La linea di release 4.21.x ha raggiunto la fine del ciclo di vita prima che questo problema fosse risolto e non riceverà una correzione, quindi i deployment su di essa devono passare a una release supportata. Sia il percorso letterale che quello risolto ora classificano l'indirizzo dai suoi byte grezzi con un unico classificatore condiviso, che riconosce fc00::/7 e lo spazio di indirizzi condiviso 100.64.0.0/10, nonché gli indirizzi compatibili IPv4, NAT64 (64:ff9b::/96) e 6to4 (2002::/16) il cui indirizzo IPv4 incorporato non è instradabile a livello globale. Per i deployment che non possono aggiornare immediatamente, porre l'autenticazione davanti al percorso di configurazione delle notifiche push A2A in modo che l'URL del webhook non arrivi da un chiamante non attendibile, e negare a livello di rete l'egress dal processo Camel verso fc00::/7; qualora il deployment non abbia bisogno di IPv6, avviare la JVM con -Djava.net.preferIPv4Stack=true rimuove la classe di indirizzi su cui si basa la lacuna. Si noti che allowLocalWebhookUrls=false è già l'impostazione predefinita e non chiude di per sé la lacuna.