An SSRF flaw exists in the Camel‑A2A push‑notification component where a webhook URL supplied in a registration request can be resolved to a private address (fc00::/7 unique local) or an IP literal. The component compares the host string directly to a list of IPv6 unique local prefixes when an IP literal is used, but when a hostname is resolved it relies on JDK predicates that do not cover the same address space. As a result, an attacker‑controlled webhook URL that resolves to an internal address may pass validation in one form and fail in another. Once accepted, the component sends a blind outbound HTTPS request to that address, together with any supplied Authorization header, exposing internal services to unauthorized access or processing. The issue is classified as CWE‑918 and can lead to confidentiality or availability compromise of internal resources.

The vulnerability affects Apache Camel versions 4.21.0 through 4.22.1, covering the A2A component introduced in 4.21.0. The fix is available in Camel 4.23.0 and, for the 4.22.x line, in 4.22.2. Deployments on the 4.21.x line are no longer supported and must migrate to a supported release.

With a CVSS score of 4.8, the flaw is rated medium severity. The EPSS score is not available, and the vulnerability is not listed in the CISA KEV catalog. The likely attack vector requires that an attacker be able to register a push‑notification webhook, either by authenticating to the Camel API or by exploiting a pathway that exposes the registration endpoint. The attacker then supplies a hostname that resolves to a private IPv6 address; the Camel process will silently perform an HTTPS request to that address, which can trigger side‑channel attacks or internal service access if TLS negotiation succeeds. While no user‑visible response is returned, the blind outbound request can be leveraged for reconnaissance or exploitation of internal services.