A2A Java SDK EUVD-2026-105043

Requires the server to have push notifications enabled, which is the DEFAULT (a2a.push-notification.enabled=true per the vendor configuration docs). An unauthenticated caller then supplies an attacker-controlled destination URL either via an inline SendMessage pushNotification config or via CreateTaskPushNotificationConfig for an existing task; BasePushNotificationSender/InMemoryPushNotificationConfigStore store and use it verbatim with no scheme restriction, destination validation, or redirect bounds. Exploitation further depends on network routing actually permitting the server to reach the chosen loopback/private/link-local/cloud-metadata/IPv6-ULA/multicast target. Key LIMITING factors: the attack is blind - the fetched response is discarded and no delivery success/failure is exposed, so there is no data read-back; a webhook redirect converts the POST to a GET and drops the body, so only direct (non-redirected) POST delivery pushes task data into internal services; and the fixed releases plus default-deny validation (allow-private-network-targets=false, https-only schemes) remove the condition once upgraded.

This is a CWE-918 Server-Side Request Forgery in the A2A Java SDK rated CVSS 5.8 (medium). The CVSS vector (AV:N/AC:L/PR:N/UI:N/S:C/C:N/I:L/A:N) aligns well with the description: network-reachable, low-complexity, unauthenticated abuse in the default configuration (push notifications enabled), with a changed scope because the forged requests leave the A2A server and reach separate internal systems. Crucially, impact is constrained - C:N and A:N with only I:L - because the sender discards the fetched response and exposes no success/failure, making this BLIND SSRF with no response read-back, and a webhook redirect downgrades the POST to a GET that drops the body. No EPSS score, KEV entry, or POC was supplied, and there is no public exploit identified at time of analysis, so the real-world exploitation signal is currently weak despite the unauthenticated, network-facing nature. Net assessment: a legitimate medium-priority SSRF worth patching (especially in cloud environments exposing 169.254.169.254 metadata endpoints), but not a drop-everything emergency - the blind, low-integrity-only impact and absence of any exploitation evidence argue against treating it as a high-real-risk issue. The vendor acknowledges residual DNS-rebinding exposure even after the fix, so network-level egress filtering remains advisable.

An unauthenticated attacker sends a message to a default A2A Java server (push notifications enabled) with an inline push-notification config pointing the webhook URL at an internal address such as the cloud metadata endpoint (169.254.169.254) or a loopback/private service. When the task's status or artifacts update, the server issues a POST from its own network position to that internal destination, pushing attacker-influenced task data into services the attacker cannot normally reach. No POC is publicly identified; exploitation is blind because the server never returns the fetched response.