Severity:
CVSS 3.1: 4.8 (medium) CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N
Affected versions:
- Apache Camel (org.apache.camel:camel-a2a) 4.21.0 before 4.22.2
- Apache Camel (org.apache.camel:camel-a2a) 4.22.2 unaffected
- Apache Camel (org.apache.camel:camel-a2a) 4.23.0 unaffected
Description:
WebhookUrlValidator in the camel-a2a component 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
pinned the address it had been handed and opened the connection to exactly that
target, and applyAuth sent along any webhook authorization header or bearer
token the deployment had configured. 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. 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.
Solution:
Upgrade to Apache Camel 4.23.0, which fixes the issue. Users on the 4.22.x
stream should upgrade to 4.22.2. Both the literal and the resolved path now
classify the address from its raw bytes with one shared classifier, which
recognises fc00::/7 along with IPv4-compatible IPv6, the NAT64 well-known
prefix 64:ff9b::/96, 6to4 under 2002::/16 and the shared address space
100.64.0.0/10. The camel-a2a component was introduced in 4.21.0 and is marked
Preview; the 4.21.x line is not a maintenance stream and does not receive a
fix, and the 4.18.x and 4.14.x lines never carried the component.
Work Arounds:
Place authentication in front of the A2A push notification configuration path
so that the webhook URL does not arrive from an untrusted caller, and deny
egress from the Camel process to fc00::/7 at the network level. Where the
deployment has no need of IPv6, starting the JVM with
-Djava.net.preferIPv4Stack=true removes the address class the gap turns on.
Setting allowLocalWebhookUrls=false is not a workaround: it is already the
default and does not close the gap.
Credit:
[email protected] (finder)
Andrea Cosentino (remediation developer)
References:
https://camel.apache.org/security/CVE-2026-71569.html
https://issues.apache.org/jira/browse/CAMEL-24371
https://github.com/apache/camel/pull/25406
https://github.com/apache/camel/pull/26583
https://camel.apache.org/
https://www.cve.org/CVERecord?id=CVE-2026-71569
