CVE-2026-71569

Zusammenfassung

Server-Side Request Forgery (SSRF)-Schwachstelle in der Apache-Camel-A2A-Komponente. Dieses Problem betrifft Apache Camel: von 4.21.0 bis vor 4.22.2. WebhookUrlValidator klassifizierte einen Push-Benachrichtigungs-Webhook-Host an zwei Stellen, die nicht übereinstimmten. Ein als IP-Literal geschriebener Host wurde gegen eine Liste von String-Präfixen abgeglichen, die den IPv6-Unique-Local-Bereich fc00::/7 benannten, während ein über einen Namen erreichter Host aufgelöst und die resultierende Adresse mit den InetAddress-Prädikaten isLoopbackAddress, isAnyLocalAddress, isLinkLocalAddress und isSiteLocalAddress klassifiziert wurde. Diese Prädikate decken nicht denselben Bereich ab wie die Präfixliste: isSiteLocalAddress meldet den veralteten Block fec0::/10 und nicht die fc00::/7-Unique-Local-Adressen, die ihn ersetzt haben, und das JDK enthält für diese überhaupt kein Prädikat. Dieselbe Adresse wurde daher je nach Schreibweise akzeptiert oder abgelehnt, und eine Webhook-URL, deren Hostname in fc00::/7 auflöste, passierte eine Prüfung, die die identische als Literal angegebene Adresse ablehnte. PushNotificationDispatcher sandte die Push-Benachrichtigung dann an diese Adresse, zusammen mit jedem Authorization-Header, der in derselben Konfiguration mitgeführt wurde, dessen Schema und Anmeldedaten der registrierende Aufrufer liefert. Die Webhook-URL kommt als TaskPushNotificationConfig.url vom Aufrufer, der die Push-Benachrichtigung registriert, ist also angreifergesteuert, und allowLocalWebhookUrls ist standardmäßig false, was die Konfiguration ist, in der die Prüfung greifen soll. Die Antwort wird nicht an den Aufrufer zurückgeleitet, der die Konfiguration registriert hat, sodass die Lücke eine blinde ausgehende HTTPS-Anfrage vom Camel-Prozess an eine interne Adresse bewirkt, die die Prüfung ablehnen sollte; das Erreichen eines Dienstes auf diesem Weg erfordert zusätzlich, dass der Name in der Zielumgebung in fc00::/7 auflöst, dass ein HTTPS-Dienst auf dieser Adresse lauscht und dass der TLS-Handshake für den angefragten Namen erfolgreich ist, weshalb die Schwere als mittel eingestuft wird. Dieselbe String-Vorprüfung war auch in die andere Richtung fehlerhaft: Sie glich den rohen Host-String ab, ohne zuvor festzustellen, dass der Host ein IP-Literal war, sodass jeder Name, der lediglich mit fc oder fd beginnt, wie etwa fcm.googleapis.com, rundheraus abgelehnt wurde. Benutzern wird empfohlen, auf Version 4.23.0 zu aktualisieren, die das Problem behebt. Befinden sich Benutzer im 4.22.x-Release-Zweig, wird ihnen empfohlen, auf 4.22.2 zu aktualisieren. Die 4.21.x-Release-Linie erreichte das Ende ihrer Lebensdauer, bevor dieses Problem behoben wurde, und erhält keinen Fix, sodass Bereitstellungen darauf auf eine unterstützte Version wechseln müssen. Sowohl der Literal- als auch der aufgelöste Pfad klassifizieren die Adresse nun anhand ihrer Rohbytes mit einem gemeinsamen Klassifizierer, der fc00::/7 und den Shared Address Space 100.64.0.0/10 erkennt sowie IPv4-kompatible, NAT64- (64:ff9b::/96) und 6to4-Adressen (2002::/16), deren eingebettete IPv4-Adresse nicht global routbar ist. Für Bereitstellungen, die nicht sofort aktualisieren können, sollte eine Authentifizierung vor den A2A-Push-Benachrichtigungs-Konfigurationspfad gesetzt werden, sodass die Webhook-URL nicht von einem nicht vertrauenswürdigen Aufrufer kommt, und der ausgehende Datenverkehr vom Camel-Prozess zu fc00::/7 auf Netzwerkebene blockiert werden; wo die Bereitstellung kein IPv6 benötigt, entfernt der Start der JVM mit -Djava.net.preferIPv4Stack=true die Adressklasse, um die sich die Lücke dreht. Beachten Sie, dass allowLocalWebhookUrls=false bereits der Standard ist und die Lücke nicht für sich allein schließt.