A2A Java SDK leaks agent API keys through HTTP redirects

Two security advisories published on 20 October 2026 describe flaws in the A2A Java SDK that let a malicious or compromised agent capture the credentials of any client that connects to it. The advisories, filed against the A2A Project's Maven packages, were assigned CVE-2026-111763 and CVE-2026-111765.

The first advisory, GHSA-9rhm-2h4x-jwmx, concerns how the SDK decides where to put a client's API key. According to the advisory, the client reads the header name from the remote agent's AgentCard, the self-description an agent serves about itself, and uses it directly as the HTTP header name for the credential. That data is controlled by the remote server and is not validated.

The advisory sets out the attack. A client configures an API key for an agent's security scheme. The agent returns an AgentCard declaring that scheme as an API key scheme with the header name X-Leaked-Cred. The SDK's authentication interceptor dutifully puts the credential in that header. The agent then answers with an HTTP 302 redirect to a server the attacker controls. The default HTTP client follows redirects, and because only the standard Authorization header is stripped when a redirect crosses to another origin, the custom header travels with it. The attacker receives the key.

The advisory also notes that the interceptor does not check whether the AgentCard actually asked for the credential to be placed in a header before doing so. It recommends validating header names against a list of safe values, checking the declared location, and disabling automatic redirects in favour of manual handling that strips authentication headers on cross-origin hops.

The second advisory, GHSA-4fpj-g9jf-9rgg, says the fix for the first one did not fully land on Android. The patch disabled redirects when creating a connection, but the synchronous POST builder in the Android HTTP client then overwrites that setting with its own default of true. The researcher reports that both the JSON-RPC and REST transports add interceptor-produced headers and call that synchronous POST without turning redirects off.

On Android's repackaged OkHttp, the advisory says, a redirect to a different authority strips Authorization but keeps non-standard headers. The interceptor permits four such names: X-API-Key, API-Key, X-Auth-Token and X-Authentication. The researcher says they confirmed that the shipped 1.3.1.Final artifact forwarded synthetic values under all four names to a second local listener, with all test traffic confined to two loopback addresses and all credentials synthetic.

The researcher states the demonstrated impact is disclosure of a complete API key or authentication token to a different authority, and makes no claim about subsequent use of the credential, code execution or host compromise. They suggest a CVSS score of 7.5 for an autonomous client, or 6.5 where a person must invoke the remote agent, while noting the project's own policy treats the parent credential-redirect issue as moderate.

The suggested fix is a one-line change flipping the Android builder's default to false, leaving an explicit opt-in. The researcher says the regression test passes after the change and that the full repository test run passes 2,914 tests with no failures. The advisory states the override remains present in 1.3.0.Final, 1.3.1.Final and current main.