{"id":"CVE-2026-111761","aliases":["EUVD-2026-105043","GHSA-q78c-5jjq-57g8"],"status":"published","title":"A2A Java SDK has Server-Side Request Forgery (SSRF) in push-notification delivery","description":"A2A Java SDK is the official Java SDK for the Agent2Agent (A2A) Protocol. Prior to 1.3.0.Final, BasePushNotificationSender in server-common sends task data to the URL in TaskPushNotificationConfig without destination validation, scheme restrictions, or bounds on redirects. InMemoryPushNotificationConfigStore.setInfo stores the URL verbatim, and onCreateTaskPushNotificationConfig does not validate the destination. In the default deployment with push notifications enabled, an unauthenticated caller can register a destination through an inline SendMessage configuration or CreateTaskPushNotificationConfig for an existing task, causing task status and artifact updates to send requests from the server's network position to loopback, private, link-local cloud-metadata, IPv6 unique-local, unspecified, or multicast destinations where routing permits. JdkA2AHttpClient and VertxA2AHttpClient follow redirects, allowing a webhook redirect to bypass creation-time destination checks and convert a POST into a GET; hostname-only checks also do not prevent DNS rebinding. Direct POST delivery can push attacker-influenced task data into internal services, whereas a redirected POST-to-GET request drops the body. The sender discards the fetched response and does not expose delivery success or failure, so the demonstrated behavior does not provide response read-back. No credentials or user interaction are required. This issue is fixed in version 1.3.0.Final.","severity":{"version":"3.1","score":5.8,"vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:N/I:L/A:N","level":"medium","assessor":"cna","from":"cve"},"epss":{"day":"2026-11-12","score":0.00586,"percentile":0.48496,"model":"v2026.06.15"},"facts":{"in_kev":false,"known_exploited":false,"public_exploit":false,"fix_available":true},"cwes":["CWE-918"],"published":"2026-10-20T14:54:46Z","modified":"2026-10-28T10:46:08Z","fixes":[{"ecosystem":"Maven","package":"org.a2aproject.sdk:a2a-java-sdk-server-common","fixed_in":["1.3.0.Final"],"sources":["ghsa","osv"]}],"affected":[{"source":"ghsa","ecosystem":"Maven","package":"org.a2aproject.sdk:a2a-java-sdk-server-common","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"1.3.0.Final"}]}]},{"source":"osv","ecosystem":"Maven","package":"org.a2aproject.sdk:a2a-java-sdk-server-common","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"1.3.0.Final"}]}],"versions":["1.0.0.Alpha4","1.0.0.Beta1","1.0.0.CR1","1.0.0.Final","1.1.0.Final","1.2.0.Final"]}],"products":[{"vendor":"a2aproject","product":"a2a-java"}],"references":[{"url":"https://github.com/a2aproject/a2a-java/security/advisories/GHSA-q78c-5jjq-57g8","tags":["x_refsource_CONFIRM","exploit","advisory","web"]},{"url":"https://github.com/a2aproject/a2a-java/pull/1096","tags":["x_refsource_MISC","fix","web"]},{"url":"https://github.com/a2aproject/a2a-java/commit/b855b2ae37e4bf23f73e7746ce166fbc5a0b8b5b","tags":["x_refsource_MISC","fix","web"]},{"url":"https://github.com/a2aproject/a2a-java/releases/tag/v1.3.0.Final","tags":["x_refsource_MISC","web"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-111761","tags":["advisory"]},{"url":"https://github.com/advisories/GHSA-q78c-5jjq-57g8"},{"url":"https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/111xxx/CVE-2026-111761.json","tags":["advisory"]},{"url":"https://github.com/a2aproject/a2a-java","tags":["package"]}],"sources":{"cve":[{"id":"CVE-2026-111761","title":"A2A Java SDK has Server-Side Request Forgery (SSRF) in push-notification delivery","description":"A2A Java SDK is the official Java SDK for the Agent2Agent (A2A) Protocol. Prior to 1.3.0.Final, BasePushNotificationSender in server-common sends task data to the URL in TaskPushNotificationConfig without destination validation, scheme restrictions, or bounds on redirects. InMemoryPushNotificationConfigStore.setInfo stores the URL verbatim, and onCreateTaskPushNotificationConfig does not validate the destination. In the default deployment with push notifications enabled, an unauthenticated caller can register a destination through an inline SendMessage configuration or CreateTaskPushNotificationConfig for an existing task, causing task status and artifact updates to send requests from the server's network position to loopback, private, link-local cloud-metadata, IPv6 unique-local, unspecified, or multicast destinations where routing permits. JdkA2AHttpClient and VertxA2AHttpClient follow redirects, allowing a webhook redirect to bypass creation-time destination checks and convert a POST into a GET; hostname-only checks also do not prevent DNS rebinding. Direct POST delivery can push attacker-influenced task data into internal services, whereas a redirected POST-to-GET request drops the body. The sender discards the fetched response and does not expose delivery success or failure, so the demonstrated behavior does not provide response read-back. No credentials or user interaction are required. This issue is fixed in version 1.3.0.Final.","status":"published","published":"2026-10-20T14:54:46.95Z","modified":"2026-10-22T21:30:39.67Z","cvss":[{"version":"3.1","score":5.8,"vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:N/I:L/A:N","level":"medium","assessor":"cna"}],"cwes":["CWE-918"],"updated_at":"2026-11-02T14:20:15.34316Z"}],"euvd":[{"id":"EUVD-2026-105043","description":"A2A Java SDK is the official Java SDK for the Agent2Agent (A2A) Protocol. Prior to 1.3.0.Final, BasePushNotificationSender in server-common sends task data to the URL in TaskPushNotificationConfig without destination validation, scheme restrictions, or bounds on redirects. InMemoryPushNotificationConfigStore.setInfo stores the URL verbatim, and onCreateTaskPushNotificationConfig does not validate the destination. In the default deployment with push notifications enabled, an unauthenticated caller can register a destination through an inline SendMessage configuration or CreateTaskPushNotificationConfig for an existing task, causing task status and artifact updates to send requests from the server's network position to loopback, private, link-local cloud-metadata, IPv6 unique-local, unspecified, or multicast destinations where routing permits. JdkA2AHttpClient and VertxA2AHttpClient follow redirects, allowing a webhook redirect to bypass creation-time destination checks and convert a POST into a GET; hostname-only checks also do not prevent DNS rebinding. Direct POST delivery can push attacker-influenced task data into internal services, whereas a redirected POST-to-GET request drops the body. The sender discards the fetched response and does not expose delivery success or failure, so the demonstrated behavior does not provide response read-back. No credentials or user interaction are required. This issue is fixed in version 1.3.0.Final.","status":"published","published":"2026-10-20T14:54:46Z","modified":"2026-10-22T21:30:39Z","cvss":[{"version":"3.1","score":5.8,"vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:N/I:L/A:N","level":"medium"}],"updated_at":"2026-11-02T16:59:33.524592Z"}],"ghsa":[{"id":"GHSA-q78c-5jjq-57g8","title":"A2A Java SDK has Server-Side Request Forgery (SSRF) in push-notification delivery","description":"---\n\n- **Ecosystem:** Maven\n- **Affected package:** `org.a2aproject.sdk:a2a-java-sdk-server-common` (push-notification delivery)\n- **Affected versions:** `\u003c= 1.2.0.Final` (and `1.2.1.Final-SNAPSHOT` on `main` prior to the fix)\n- **Patched version:** _(the release that carries the fix)_\n- **CWE:** CWE-918 (Server-Side Request Forgery)\n- **Severity:** High\n- **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)\n\n---\n\n## Summary\n\nAn **unauthenticated** attacker can coerce the a2a-java server into issuing HTTP requests to\narbitrary internal and cloud-metadata endpoints from the server's own network position — a\nServer-Side Request Forgery reachable in the default deployment with no credentials, no user\ninteraction, and a single request. The behaviour is the shipped default, not a misconfiguration.\n\n## Details\n\n`BasePushNotificationSender` (in `server-common`) POSTs task data to the URL stored on a task's\n`TaskPushNotificationConfig` with no validation of the destination: no block on loopback, RFC1918,\nlink-local (`169.254.0.0/16`, including the `169.254.169.254` metadata address), unique-local,\nunspecified, or multicast ranges; no scheme restriction; and no bound on redirects.\n`InMemoryPushNotificationConfigStore.setInfo` stores the URL verbatim and\n`onCreateTaskPushNotificationConfig` does not check it either.\n\nBoth shipped HTTP clients follow redirects (`JdkA2AHttpClient` → `followRedirects(NORMAL)`,\n`VertxA2AHttpClient` → `setFollowRedirects(true)`), so a creation-time URL allowlist is bypassable:\nan attacker webhook answers `302 Location: http://169.254.169.254/...` and the client follows it. A\nhostname check is likewise defeated by DNS rebinding. A correct guard must validate the *resolved*\nIP of every hop at connection time, not the URL string.\n\n## Exploitation\n\nDemonstrated end-to-end against a running server (default wiring, unauthenticated caller):\n\n- **Arbitrary internal reachability.** The attacker picks the destination and the server issues\n  the request from inside the trust boundary. Delivery to loopback and to a real RFC1918 LAN\n  address was exercised at runtime; because the code applies no destination filtering of any kind,\n  the same path reaches link-local / metadata (`169.254.169.254`) and other internal ranges\n  wherever network routing permits.\n- **Allowlist + method bypass via redirect.** A `302` from the attacker's webhook reaches\n  destinations a creation-time allowlist would block, and a `302` on a `POST` is followed as a\n  `GET` — so GET-only endpoints such as the IMDS credentials path are reachable even though the\n  sender only issues `POST`s. This is why a URL allowlist is not a sufficient fix; the guard must\n  validate the resolved IP of every redirect hop.\n- **Data push into internal services.** On direct (non-redirected) delivery, each request carries\n  the task payload in the body, so internal services that ingest POST data receive\n  attacker-influenced content (basis for `I:L`). On a redirected request the body is dropped in the\n  POST→GET conversion, so the body-push and the redirect-reach are separate capabilities, not\n  simultaneous on one request.\n\nThe sender discards the fetched response and exposes no caller-visible difference between a\nsuccessful and a failed delivery (both paths return without surfacing status or body), so the base\ncase reads back nothing — confidentiality is scored `C:N`. Read-back is limited, reach is not: the\nattacker still drives fully controlled requests to metadata and internal services and writes data\ninto them.\n\n## PoC\n\nAgainst a running server with push notifications enabled (JSON-RPC transport), using only the real\nproduction classes wired the default way:\n\n1. Start a local listener standing in for an internal target (no real metadata service is touched).\n2. Send one `SendMessage` that starts a long-running task, with the push config inlined and its\n   `url` set to `http://\u003cinternal-target\u003e/latest/meta-data/iam/security-credentials/`. Use\n   `returnImmediately: true`, header `A2A-Version: 1.0`, and role `ROLE_USER`. The URL is stored\n   verbatim. (Equivalent via `CreateTaskPushNotificationConfig` on an existing task.)\n3. As the task emits state/artifact updates, the sender POSTs each one to the stored URL, from the\n   server's own network position:\n\n   ```\n   POST /latest/meta-data/iam/security-credentials/ HTTP/1.1\n   Host: 169.254.169.254\n   Content-Type: application/json\n\n   {\"artifactUpdate\":{\"taskId\":\"...\",\"artifact\":{\"parts\":[{\"text\":\"Progress update 1/20\"}]}, ...}}\n   ```\n\nOne `SendMessage` produced multiple server-side POSTs to the attacker-chosen internal path.\nVerified on `main` (commit `72d220c`, JDK 21) and unchanged on `1.2.0.Final`.\n\n## Remediation\n\nValidate the *resolved* IP of the target and of every redirect hop before connecting: reject\nloopback / RFC1918 / link-local / metadata / unique-local / unspecified / multicast; restrict the\nscheme to `http`/`https`; cap redirects; and resolve-and-pin to defeat DNS rebinding. Enable by\ndefault, with a documented opt-out for deployments that intentionally target internal webhooks. The\nGo A2A SDK ships a dial-time resolved-IP guard of this shape by default.\n\n**Workaround:** until a fixed release, block the host's outbound egress to the metadata endpoint\nand internal ranges at the network layer.\n\n## References\n\n- CWE-918: Server-Side Request Forgery: https://cwe.mitre.org/data/definitions/918.html","status":"published","published":"2026-10-20T21:06:22Z","modified":"2026-10-20T21:06:23Z","cvss":[{"version":"3.1","score":5.8,"vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:N/I:L/A:N","level":"medium"}],"cwes":["CWE-918"],"updated_at":"2026-11-02T14:41:33.669646Z"}],"nvd":[{"id":"CVE-2026-111761","description":"A2A Java SDK is the official Java SDK for the Agent2Agent (A2A) Protocol. Prior to 1.3.0.Final, BasePushNotificationSender in server-common sends task data to the URL in TaskPushNotificationConfig without destination validation, scheme restrictions, or bounds on redirects. InMemoryPushNotificationConfigStore.setInfo stores the URL verbatim, and onCreateTaskPushNotificationConfig does not validate the destination. In the default deployment with push notifications enabled, an unauthenticated caller can register a destination through an inline SendMessage configuration or CreateTaskPushNotificationConfig for an existing task, causing task status and artifact updates to send requests from the server's network position to loopback, private, link-local cloud-metadata, IPv6 unique-local, unspecified, or multicast destinations where routing permits. JdkA2AHttpClient and VertxA2AHttpClient follow redirects, allowing a webhook redirect to bypass creation-time destination checks and convert a POST into a GET; hostname-only checks also do not prevent DNS rebinding. Direct POST delivery can push attacker-influenced task data into internal services, whereas a redirected POST-to-GET request drops the body. The sender discards the fetched response and does not expose delivery success or failure, so the demonstrated behavior does not provide response read-back. No credentials or user interaction are required. This issue is fixed in version 1.3.0.Final.","status":"published","published":"2026-10-20T15:17:11.823Z","modified":"2026-10-22T22:18:01.23Z","cvss":[{"version":"3.1","score":5.8,"vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:N/I:L/A:N","level":"medium","assessor":"secondary"}],"cwes":["CWE-918"],"updated_at":"2026-11-02T14:13:01.161484Z"}],"osv":[{"id":"CVE-2026-111761","title":"A2A Java SDK has Server-Side Request Forgery (SSRF) in push-notification delivery","description":"A2A Java SDK is the official Java SDK for the Agent2Agent (A2A) Protocol. Prior to 1.3.0.Final, BasePushNotificationSender in server-common sends task data to the URL in TaskPushNotificationConfig without destination validation, scheme restrictions, or bounds on redirects. InMemoryPushNotificationConfigStore.setInfo stores the URL verbatim, and onCreateTaskPushNotificationConfig does not validate the destination. In the default deployment with push notifications enabled, an unauthenticated caller can register a destination through an inline SendMessage configuration or CreateTaskPushNotificationConfig for an existing task, causing task status and artifact updates to send requests from the server's network position to loopback, private, link-local cloud-metadata, IPv6 unique-local, unspecified, or multicast destinations where routing permits. JdkA2AHttpClient and VertxA2AHttpClient follow redirects, allowing a webhook redirect to bypass creation-time destination checks and convert a POST into a GET; hostname-only checks also do not prevent DNS rebinding. Direct POST delivery can push attacker-influenced task data into internal services, whereas a redirected POST-to-GET request drops the body. The sender discards the fetched response and does not expose delivery success or failure, so the demonstrated behavior does not provide response read-back. No credentials or user interaction are required. This issue is fixed in version 1.3.0.Final.","status":"published","published":"2026-10-20T14:54:46.95Z","modified":"2026-10-28T10:46:08.047015602Z","cvss":[{"version":"3.1","score":5.8,"vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:N/I:L/A:N","level":"medium"}],"cwes":["CWE-918"],"updated_at":"2026-11-02T15:44:55.938017Z"},{"id":"GHSA-q78c-5jjq-57g8","title":"A2A Java SDK has Server-Side Request Forgery (SSRF) in push-notification delivery","description":"---\n\n- **Ecosystem:** Maven\n- **Affected package:** `org.a2aproject.sdk:a2a-java-sdk-server-common` (push-notification delivery)\n- **Affected versions:** `\u003c= 1.2.0.Final` (and `1.2.1.Final-SNAPSHOT` on `main` prior to the fix)\n- **Patched version:** _(the release that carries the fix)_\n- **CWE:** CWE-918 (Server-Side Request Forgery)\n- **Severity:** High\n- **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)\n\n---\n\n## Summary\n\nAn **unauthenticated** attacker can coerce the a2a-java server into issuing HTTP requests to\narbitrary internal and cloud-metadata endpoints from the server's own network position — a\nServer-Side Request Forgery reachable in the default deployment with no credentials, no user\ninteraction, and a single request. The behaviour is the shipped default, not a misconfiguration.\n\n## Details\n\n`BasePushNotificationSender` (in `server-common`) POSTs task data to the URL stored on a task's\n`TaskPushNotificationConfig` with no validation of the destination: no block on loopback, RFC1918,\nlink-local (`169.254.0.0/16`, including the `169.254.169.254` metadata address), unique-local,\nunspecified, or multicast ranges; no scheme restriction; and no bound on redirects.\n`InMemoryPushNotificationConfigStore.setInfo` stores the URL verbatim and\n`onCreateTaskPushNotificationConfig` does not check it either.\n\nBoth shipped HTTP clients follow redirects (`JdkA2AHttpClient` → `followRedirects(NORMAL)`,\n`VertxA2AHttpClient` → `setFollowRedirects(true)`), so a creation-time URL allowlist is bypassable:\nan attacker webhook answers `302 Location: http://169.254.169.254/...` and the client follows it. A\nhostname check is likewise defeated by DNS rebinding. A correct guard must validate the *resolved*\nIP of every hop at connection time, not the URL string.\n\n## Exploitation\n\nDemonstrated end-to-end against a running server (default wiring, unauthenticated caller):\n\n- **Arbitrary internal reachability.** The attacker picks the destination and the server issues\n  the request from inside the trust boundary. Delivery to loopback and to a real RFC1918 LAN\n  address was exercised at runtime; because the code applies no destination filtering of any kind,\n  the same path reaches link-local / metadata (`169.254.169.254`) and other internal ranges\n  wherever network routing permits.\n- **Allowlist + method bypass via redirect.** A `302` from the attacker's webhook reaches\n  destinations a creation-time allowlist would block, and a `302` on a `POST` is followed as a\n  `GET` — so GET-only endpoints such as the IMDS credentials path are reachable even though the\n  sender only issues `POST`s. This is why a URL allowlist is not a sufficient fix; the guard must\n  validate the resolved IP of every redirect hop.\n- **Data push into internal services.** On direct (non-redirected) delivery, each request carries\n  the task payload in the body, so internal services that ingest POST data receive\n  attacker-influenced content (basis for `I:L`). On a redirected request the body is dropped in the\n  POST→GET conversion, so the body-push and the redirect-reach are separate capabilities, not\n  simultaneous on one request.\n\nThe sender discards the fetched response and exposes no caller-visible difference between a\nsuccessful and a failed delivery (both paths return without surfacing status or body), so the base\ncase reads back nothing — confidentiality is scored `C:N`. Read-back is limited, reach is not: the\nattacker still drives fully controlled requests to metadata and internal services and writes data\ninto them.\n\n## PoC\n\nAgainst a running server with push notifications enabled (JSON-RPC transport), using only the real\nproduction classes wired the default way:\n\n1. Start a local listener standing in for an internal target (no real metadata service is touched).\n2. Send one `SendMessage` that starts a long-running task, with the push config inlined and its\n   `url` set to `http://\u003cinternal-target\u003e/latest/meta-data/iam/security-credentials/`. Use\n   `returnImmediately: true`, header `A2A-Version: 1.0`, and role `ROLE_USER`. The URL is stored\n   verbatim. (Equivalent via `CreateTaskPushNotificationConfig` on an existing task.)\n3. As the task emits state/artifact updates, the sender POSTs each one to the stored URL, from the\n   server's own network position:\n\n   ```\n   POST /latest/meta-data/iam/security-credentials/ HTTP/1.1\n   Host: 169.254.169.254\n   Content-Type: application/json\n\n   {\"artifactUpdate\":{\"taskId\":\"...\",\"artifact\":{\"parts\":[{\"text\":\"Progress update 1/20\"}]}, ...}}\n   ```\n\nOne `SendMessage` produced multiple server-side POSTs to the attacker-chosen internal path.\nVerified on `main` (commit `72d220c`, JDK 21) and unchanged on `1.2.0.Final`.\n\n## Remediation\n\nValidate the *resolved* IP of the target and of every redirect hop before connecting: reject\nloopback / RFC1918 / link-local / metadata / unique-local / unspecified / multicast; restrict the\nscheme to `http`/`https`; cap redirects; and resolve-and-pin to defeat DNS rebinding. Enable by\ndefault, with a documented opt-out for deployments that intentionally target internal webhooks. The\nGo A2A SDK ships a dial-time resolved-IP guard of this shape by default.\n\n**Workaround:** until a fixed release, block the host's outbound egress to the metadata endpoint\nand internal ranges at the network layer.\n\n## References\n\n- CWE-918: Server-Side Request Forgery: https://cwe.mitre.org/data/definitions/918.html","status":"published","published":"2026-10-20T21:06:22Z","modified":"2026-10-20T21:15:04.05969001Z","cvss":[{"version":"3.1","score":5.8,"vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:N/I:L/A:N","level":"medium"}],"cwes":["CWE-918"],"updated_at":"2026-11-02T15:46:54.055966Z"}]}}