# CVE-2026-111763 A2A Java SDK API Key Leak: Chain, Fix

> Teardown of CVE-2026-111763 in the A2A Java SDK: how a hostile AgentCard and a redirect leak an API key, the 1.3.0.Final fix, and what to check.

Source: https://playciso.com/blog/cve-2026-111763-a2a-java-sdk-api-key-leak-chain-fix · Published: 2026-11-04 · Publisher: PlayCISO (https://playciso.com)

Primary source: https://github.com/a2aproject/a2a-java/security/advisories/GHSA-9rhm-2h4x-jwmx

---

**CVE-2026-111763** is a vulnerability in the **A2A Java SDK**, the official Java SDK for the Agent2Agent (A2A) protocol that lets AI agents call each other. According to the NVD record, before version **1.3.0.Final** "a malicious or compromised remote agent can cause the default JDK-based client to forward a configured API key to a third-party server." It was published in GitHub's advisory database on **28 August 2026** and in NVD on **20 October 2026**. It is a good case for agent-to-agent security because the bug is what you would expect when one agent trusts another agent's description of itself. _This is a teardown of advisories written by the project and its reporters. PlayCISO did not discover the flaw and has not tested it. Facts were checked on 4 November 2026 and are attributed to their source. The chain is explained at a conceptual level: no exploit code, payloads or proof-of-concept._ Confirmed vs not yet known **Confirmed by the advisory and NVD:** the A2A Java SDK sent the API key in a header whose name came from the remote agent's AgentCard, the default client follows redirects and forwards custom headers across origins, fixed in 1.3.0.Final. Weakness: CWE-522, insufficiently protected credentials. **Score:** CVSS 4.0 base 5.7 Medium from GitHub as CNA. NVD status was "Awaiting Analysis" with no NVD score. GitHub's advisory page says severity "Moderate". **Sources differ on the affected range:** NVD says "prior to 1.3.0.Final"; the advisory lists 1.2.0.Final as the affected version. **No A2A protocol-level CVE found.** A keyword search of NVD for "agent2agent" returned only five A2A Java SDK records. One search is not proof that none exists. **Not known:** whether the flaw was ever used against a real deployment. The advisories describe disclosure of a credential, not misuse, and we found no report of exploitation. ## What the weakness was In A2A, a client agent learns how to talk to a remote agent from that agent's **AgentCard**, a published description of its endpoints and security schemes. An API-key scheme in the card includes a name for the header the key should be sent in. The card is data supplied by the very party the client is about to authenticate to. The advisory GHSA-9rhm-2h4x-jwmx says the SDK's `AuthInterceptor` used the header name from the untrusted card as the name of the header carrying the client's credential, and did not check that the scheme's declared location was a header. Separately, the default `JdkA2AHttpClient` follows redirects, and the JDK strips only the standard `Authorization` header when it follows one to another origin. ## The attack chain, step by step (conceptual) - Preconditions. A client application has configured API-key credentials through the SDK's CredentialService for the agent's security scheme, and talks to a remote agent that is malicious or has been compromised. The default JDK client is in use. - The client reads the AgentCard. The card, controlled by the remote agent, declares an API-key scheme with a header name of the agent's choosing. - The SDK puts the key where the card says. The interceptor adds the credential under that name without checking the declared location. - The agent answers with a redirect to another origin. This is the second thing the agent controls, per the NVD description. - The client follows it. The default client uses normal redirect following. The standard Authorization header is dropped on a cross-origin hop, but the custom header is kept. - The third-party server receives the key. The credential has left the trust relationship it was issued for. The advisory is careful about the limits: it needs a configured API key, an agent that controls its card and its redirect, and no additional client privileges. ## Impact, as reported - NVD / GitHub CNA: disclosure of a configured API key to a third party. The CNA's CVSS 4.0 vector is local attack vector, attack requirements present, low privileges, no user interaction, high confidentiality impact on the vulnerable system and none on others, score 5.7. - CISA SSVC entry on the NVD record (21 October 2026): exploitation none, automatable no, technical impact partial. - Not claimed: code execution, host compromise or what the attacker does with the key. For the follow-up Android flaw, the reporter says the demonstrated impact is credential disclosure only. ## The fix, exactly as documented - Upgrade to 1.3.0.Final. The 1.3.0.Final release notes list PR #1097, "fix: prevent credential leakage via header injection and redirects". NVD references that fix. - Workarounds from the advisory: validate the API key scheme name against an allowlist of safe header names; confirm the scheme's location is HEADER before adding a credential to a header; consider disabling automatic redirects and handling them manually, stripping all authentication headers on cross-origin hops. - Android client: the first fix did not fully hold. GHSA-4fpj-g9jf-9rgg (CVE-2026-111765, published 9 September 2026, found by north-echo) says the synchronous POST path re-enabled redirects, and that Android's HTTP stack keeps custom API-key headers (X-API-Key, API-Key, X-Auth-Token, X-Authentication) on cross-authority redirects. It affects 1.3.0.Final through 1.3.1.Final and is fixed in 1.3.2.Final. Interim workaround: call followRedirects(false) on POST requests. ## The same release fixed other A2A SDK issues The NVD keyword search returned four more A2A Java SDK records published on 20 October 2026, all fixed in 1.3.0.Final per their descriptions. Each is rated by GitHub as CNA; NVD's own analysis is pending. - CVE-2026-111761 (CWE-918, CVSS 3.1 5.8): push-notification URLs were not validated, so a caller could make the server send requests to internal destinations. - CVE-2026-111762 (CWE-532, CVSS 4.0 5.7): a failed request parse logged the full body, including push-notification credentials, in cleartext. - CVE-2026-111764 (CWE-862, CVSS 3.1 7.5): the default in-memory task store did no authorization on task reads, so a caller who knew or guessed a task ID could read another caller's task data. If you run A2A servers, not just clients, read those records too. ## Timeline DateEventSource 31 Oct 2025Unit 42 publishes "Agent Session Smuggling in A2A Systems": research, no CVE, no protocol vulnerability claimed.Unit 42 article 27 Aug 2026v1.3.0.Final released (the page shows day and month only).a2a-java release page 28 Aug 2026GHSA-9rhm-2h4x-jwmx published (reporter: ehsavoie; severity Moderate).GitHub advisory 9 Sep 2026GHSA-4fpj-g9jf-9rgg published for the Android residual flaw; fixed in 1.3.2.Final.GitHub advisory 20 Oct 2026CVE-2026-111763 and four sibling A2A Java SDK CVEs published in NVD.NVD CVE API 21 Oct 2026CVE-2026-111763 last modified in NVD; status "Awaiting Analysis".NVD CVE API, fetched 4 Nov 2026 ## What security teams should check this week - Find A2A Java SDK use. Look for org.a2aproject.sdk artifacts in your dependency trees, including transitive use through agent frameworks. Anything before 1.3.0.Final is in scope; Android users need 1.3.2.Final. - Rotate API keys that ever went to a remote agent you do not control from a vulnerable client. The advisory reports disclosure, not use, so rotate on risk, not on proof. - Keep an allowlist of agents. Our suggestion: a client should only talk to AgentCards it has been told to trust, and treat the card as untrusted input, like any web response. - Scope credentials per agent. One key per remote agent, with the narrowest rights, so a leak costs one integration. See the Agent Credential Broker Lab and the Non-Human Identity Risk Checklist. - Review redirect handling in every agent HTTP client, not just this SDK: disable automatic redirects for authenticated calls or strip every credential-bearing header on a cross-origin hop. - Watch egress. Alert on requests from agent hosts that carry credential headers to hosts that are not on your approved list. - If you run A2A servers, check task authorization, push-notification URL validation and log redaction against the sibling records above. - Practise the decision. Rehearse what an agent should accept from another agent in the Inter-Agent Sanitization Lab, and read how to secure an AI agent orchestrator. ## About agent session smuggling If you came here from the Palo Alto Networks Unit 42 research, note the difference. Unit 42 (Royce Lu and Jay Chen, 31 October 2025) describes a malicious remote agent abusing an established A2A session to send hidden extra instructions to a client agent. Its lab demonstrations used Google's Agent Development Kit and, it says, it has "not observed the attack in the wild". The article states that "This research does not reveal any vulnerability in the A2A protocol itself", assigns no CVE and describes no vendor or maintainer response. Its mitigations: out-of-band human approval for sensitive actions, grounding each session in the user's original intent, verifying agents with signed AgentCards, and showing users the client agent's activity. Both stories point to the same rule: what an agent says about itself, or sends mid-session, is untrusted input. ## FAQ ### What is CVE-2026-111763? A credential-leak vulnerability in the A2A Java SDK, the official Java SDK for the Agent2Agent (A2A) protocol. Per the NVD record, before 1.3.0.Final "a malicious or compromised remote agent can cause the default JDK-based client to forward a configured API key to a third-party server." ### Is there a CVE in the A2A protocol itself? We did not find one. On 4 November 2026 a keyword search of the NVD CVE API for "agent2agent" returned five records, all for the A2A Java SDK (CVE-2026-111761 to CVE-2026-111765), not the protocol specification. That is one search, not proof that none exists. The Unit 42 session-smuggling research (31 October 2025) says it "does not reveal any vulnerability in the A2A protocol itself" and cites no CVE. ### Which versions of the A2A Java SDK are affected and what is fixed? The NVD description says "prior to 1.3.0.Final" and that 1.3.0.Final fixes it. The GitHub advisory GHSA-9rhm-2h4x-jwmx lists 1.2.0.Final as the affected version and 1.3.0.Final as patched, so the two differ in how they state the range; treat anything before 1.3.0.Final as in scope. A follow-up flaw in the Android HTTP client (CVE-2026-111765, GHSA-4fpj-g9jf-9rgg) affects 1.3.0.Final through 1.3.1.Final and is fixed in 1.3.2.Final. ### What is the CVSS score of CVE-2026-111763? The NVD record shows a CVSS 4.0 base score of 5.7 Medium, supplied by GitHub as CNA (vector CVSS:4.0/AV:L/AC:L/AT:P/PR:L/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N). NVD had not added its own score; the record status was "Awaiting Analysis". The GitHub advisory page rates it "Moderate" and shows no score. The related Android flaw, CVE-2026-111765, is scored 7.5 High (CVSS 3.1) by GitHub as CNA. ### How does the attack work? A client configures an API key for an agent. The agent's public AgentCard, which the remote agent controls, names the HTTP header the key should travel in. Per the advisory, the SDK used that name without checking the scheme's declared location, and the default HTTP client follows redirects while stripping only the standard Authorization header. A malicious or compromised agent can therefore redirect the client to another server, and the custom header carrying the key goes along. ### Does the attacker get to use the stolen key? The advisories describe disclosure of the credential, not its use. For the Android follow-up the reporter says the demonstrated impact is "credential disclosure, not subsequent credential use, integrity or availability impact, code execution, or host compromise". Whether a leaked key is useful depends on what it opens, so rotate it. ### What is the fix or workaround? Upgrade to 1.3.0.Final (and to 1.3.2.Final if you use the Android HTTP client). The advisory also recommends validating the API key scheme name against an allowlist of safe header names, confirming the scheme's location is HEADER before placing a credential in a header, and considering disabling automatic redirects and handling them manually, stripping all authentication headers on cross-origin hops. ### Is this the same as agent session smuggling? No. Session smuggling, described by Palo Alto Networks Unit 42 on 31 October 2025, is research about a malicious remote agent sending hidden follow-up instructions inside a session to a client agent. It is a design-level risk with lab demonstrations and no CVE. CVE-2026-111763 is a concrete SDK bug. They share one cause worth fixing: trusting what a remote agent says about itself. ### Did Google or the A2A maintainers respond to the Unit 42 research? The Unit 42 article does not describe any response from the A2A protocol maintainers, Google or the ADK team, and says the findings were shared with Cyber Threat Alliance members. We did not find a separate response on our searches, so we do not claim one. ## Sources - GitHub Security Advisory GHSA-9rhm-2h4x-jwmx: Client credentials sent under server-controlled HTTP header name, enabling leakage via redirect (a2aproject/a2a-java; CVE-2026-111763; published 28 August 2026; patched 1.3.0.Final) - NVD record for CVE-2026-111763 (published 20 October 2026; GitHub CNA CVSS 4.0 5.7; CWE-522), read through the NVD CVE API on 4 November 2026 - GitHub Security Advisory GHSA-4fpj-g9jf-9rgg (CVE-2026-111765, Android residual; published 9 September 2026; fixed in 1.3.2.Final) and its NVD record - a2a-java v1.3.0.Final release notes (PRs #1095, #1096, #1097 among the security-related changes) - NVD records for the sibling CVEs CVE-2026-111761, CVE-2026-111762 and CVE-2026-111764 - Palo Alto Networks Unit 42: Agent Session Smuggling in Agent2Agent Systems (31 October 2025; research, no CVE) _This article is educational guidance for security and engineering leaders, not legal advice or a forensic report. It describes published, fixed vulnerabilities at a defensive level. Check the advisories for the latest status before acting._