CVE-2026-111761: CWE-918: Server-Side Request Forgery (SSRF) in a2aproject a2a-java

--- - **Ecosystem:** Maven - **Affected package:** `org.a2aproject.sdk:a2a-java-sdk-server-common` (push-notification delivery) - **Affected versions:** `<= 1.2.0.Final` (and `1.2.1.Final-SNAPSHOT` on `main` prior to the fix) - **Patched version:** _(the release that carries the fix)_ - **CWE:** CWE-918 (Server-Side Request Forgery) - **Severity:** High - **CVSS v3.1:** `CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:N/I:L/A:N` (5.8, Moderate) --- ## Summary An **unauthenticated** attacker can coerce the a2a-java server into issuing HTTP requests to arbitrary internal and cloud-metadata endpoints from the server's own network position — a Server-Side Request Forgery reachable in the default deployment with no credentials, no user interaction, and a single request. The behaviour is the shipped default, not a misconfiguration. ## Details `BasePushNotificationSender` (in `server-common`) POSTs task data to the URL stored on a task's `TaskPushNotificationConfig` with no validation of the destination: no block on loopback, RFC1918, link-local (`169.254.0.0/16`, including the `169.254.169.254` metadata address), unique-local, unspecified, or multicast ranges; no scheme restriction; and no bound on redirects. `InMemoryPushNotificationConfigStore.setInfo` stores the URL verbatim and `onCreateTaskPushNotificationConfig` does not check it either. Both shipped HTTP clients follow redirects (`JdkA2AHttpClient` → `followRedirects(NORMAL)`, `VertxA2AHttpClient` → `setFollowRedirects(true)`), so a creation-time URL allowlist is bypassable: an attacker webhook answers `302 Location: http://169.254.169.254/...` and the client follows it. A hostname check is likewise defeated by DNS rebinding. A correct guard must validate the *resolved* IP of every hop at connection time, not the URL string. ## Exploitation Demonstrated end-to-end against a running server (default wiring, unauthenticated caller): - **Arbitrary internal reachability.** The attacker picks the destination and the server issues the request from inside the trust boundary. Delivery to loopback and to a real RFC1918 LAN address was exercised at runtime; because the code applies no destination filtering of any kind, the same path reaches link-local / metadata (`169.254.169.254`) and other internal ranges wherever network routing permits. - **Allowlist + method bypass via redirect.** A `302` from the attacker's webhook reaches destinations a creation-time allowlist would block, and a `302` on a `POST` is followed as a `GET` — so GET-only endpoints such as the IMDS credentials path are reachable even though the sender only issues `POST`s. This is why a URL allowlist is not a sufficient fix; the guard must validate the resolved IP of every redirect hop. - **Data push into internal services.** On direct (non-redirected) delivery, each request carries the task payload in the body, so internal services that ingest POST data receive attacker-influenced content (basis for `I:L`). On a redirected request the body is dropped in the POST→GET conversion, so the body-push and the redirect-reach are separate capabilities, not simultaneous on one request. The sender discards the fetched response and exposes no caller-visible difference between a successful and a failed delivery (both paths return without surfacing status or body), so the base case reads back nothing — confidentiality is scored `C:N`. Read-back is limited, reach is not: the attacker still drives fully controlled requests to metadata and internal services and writes data into them. ## PoC Against a running server with push notifications enabled (JSON-RPC transport), using only the real production classes wired the default way: 1. Start a local listener standing in for an internal target (no real metadata service is touched). 2. Send one `SendMessage` that starts a long-running task, with the push config inlined and its `url` set to `http://<internal-target>/latest/meta-data/iam/security-credentials/`. Use `returnImmediately: true`, header `A2A-Version: 1.0`, and role `ROLE_USER`. The URL is stored verbatim. (Equivalent via `CreateTaskPushNotificationConfig` on an existing task.) 3. As the task emits state/artifact updates, the sender POSTs each one to the stored URL, from the server's own network position: ``` POST /latest/meta-data/iam/security-credentials/ HTTP/1.1 Host: 169.254.169.254 Content-Type: application/json {"artifactUpdate":{"taskId":"...","artifact":{"parts":[{"text":"Progress update 1/20"}]}, ...}} ``` One `SendMessage` produced multiple server-side POSTs to the attacker-chosen internal path. Verified on `main` (commit `72d220c`, JDK 21) and unchanged on `1.2.0.Final`. ## Remediation Validate the *resolved* IP of the target and of every redirect hop before connecting: reject loopback / RFC1918 / link-local / metadata / unique-local / unspecified / multicast; restrict the scheme to `http`/`https`; cap redirects; and resolve-and-pin to defeat