CVE-2026-71569
Camel-A2A: Push notification webhook guard accepts IPv6 unique local addresses reached through a host name, enabling blind server-side request forgery
Description
WebhookUrlValidator classified a push notification webhook host in two places that did not agree. A host written as an IP literal was matched against a list of string prefixes that named the IPv6 unique local range fc00::/7, while a host reached through a name was resolved and the resulting address classified with the InetAddress predicates isLoopbackAddress, isAnyLocalAddress, isLinkLocalAddress and isSiteLocalAddress. Those predicates do not cover the same ground as the prefix list: isSiteLocalAddress reports the deprecated fec0::/10 block and not the fc00::/7 unique local addresses that replaced it, and the JDK carries no predicate for them at all. The same address was therefore accepted or rejected depending on how it was written, and a webhook URL whose host name resolved into fc00::/7 passed a guard that refused the identical address given as a literal. PushNotificationDispatcher then sent the push notification to that address, together with any Authorization header carried in the same configuration, whose scheme and credentials the registering caller supplies. The webhook URL arrives as TaskPushNotificationConfig.url from the caller registering the push notification, so it is attacker-controlled, and allowLocalWebhookUrls is false by default, which is the configuration in which the guard is expected to hold. The response is not relayed back to the caller who registered the configuration, so what the gap yields is a blind outbound HTTPS request from the Camel process to an internal address the guard was written to refuse; reaching a service that way additionally requires that the name resolve into fc00::/7 in the target environment, that an HTTPS service be listening on that address, and that the TLS handshake succeed for the name being requested, which is why the severity is assessed medium. The same string pre-check was also wrong in the other direction: it matched the raw host string without first establishing that the host was an IP literal, so any name merely beginning with fc or fd, such as fcm.googleapis.com, was refused outright.
Mitigation
Credit
This issue was discovered by 2122295973 at qq dot com and reported through the ASF Security Team
Notes
The JIRA ticket: https://issues.apache.org/jira/browse/CAMEL-24371 refers to the commits that resolved the issue, and has more details.
The fix was merged on main in https://github.com/apache/camel/pull/25406 (commit 54041cce545322f7ff1bb362ecc02999b3d96ba0), and backported to camel-4.22.x in https://github.com/apache/camel/pull/26583 (commit c4a5c5fc968763474d0c6b0f8d840cee68c09142).
Both paths now go through InetAddress.getByName, which parses a bracketed IPv6 literal without touching DNS, and classify the resulting address from its raw bytes, so a host is judged by the address it denotes rather than by how it was spelled. The string pre-check is gone, so names such as fcm.googleapis.com are resolved and classified like any other name. NAT64 and 6to4 addresses carrying a globally routable IPv4 address remain allowed, so an IPv6-only deployment can still reach public webhook endpoints through a translation prefix. The allowLocalWebhookUrls option is unchanged: it still permits loopback targets only, for local development, and does not permit any of the ranges above.
The camel-a2a component was introduced in 4.21.0 and is marked Preview, so the affected range starts at that release; the 4.18.x and 4.14.x lines never carried the component.
This issue is distinct from the DNS pinning added in 4.22.0 by https://issues.apache.org/jira/browse/CAMEL-23876, which makes the dispatcher connect to the address the guard validated instead of resolving the host name a second time. Pinning works as intended; the gap described here is in how that address was classified, and it affects releases with and without pinning alike. The issue is classified as CWE-918 (Server-Side Request Forgery).